本文主要是介绍敏捷(Agile)工作方法到底能帮你解决什么问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
团队工作效率很低，客户对产品不满意，老板对团队工作挑三拣四，个别同事总在拖后进度，个人职业生涯发展有限.....工作中会有各种各样的问题发生。
敏捷工作(Agile)方法，现在这麽流行，它到底能帮我解决哪些问题呢？
在我的教练生涯里，无数次面对这种提问。 既然它被问的如此普遍，那么就值得归纳分享一下了。
对这个问题，我的观点主要有两个：
- 敏捷不能解决任何问题， 解决问题的是人。
- 敏捷能解决什么具体问题不重要，敏捷为什么这样设计很重要。
敏捷不能解决任何问题， 解决问题的是人
如果敏捷是一个工具，那么必须是人去使用工具。工具能发挥多大作用，要依赖于人对工具的掌握程度，以及怎么去灵活使用。
人能不能解决问题，首先取决于解决问题的渴望，其次取决于方法。敏捷充其量算是方法中的一种。
渴望不同于愿望。愿望谁都有，毕竟面对工作中的难题和挑战，谁不想去解决呢？谁不想变的更好呢？
但同时你可能常听到一个说法，叫做『有些问题没解决，是因为还没逼到份上』。没错，想解决问题，只有愿望，不一定会产生行动，而且有可能永远都没有行动，只是一个"美好的愿望"。 『逼到份上』则是在问题本身之上，增加了紧迫性，必要性，和马上就面临的损失。这些因素将愿望逼成了渴望，而渴望，会促使行动的马上发生。
你看，解决问题，不是你想不想，而是你动没动，你动不动，背后的原因是你到底有多渴望。
除了紧迫感之外，使命感，纪律性，强烈的兴趣等都会促成对解决问题的渴望。渴望是第一位的，当你不渴望的时候， 方法能起作用极其有限。
《高效能人士的7个习惯》里提到的『个人愿景原则』，和『自我管理原则』，就分别指的是使命感和纪律性，二者都能形成渴望，推动人去迅速行动，也就比普通人更加高效能了。
前阵子有个团队跟我抱怨，说客户并不满意，团队尝试过很多方法去解决，并没有奏效，希望看看敏捷方法是否能帮助到他们。
我做了一番访谈后，发现一方面是团队很忙，另一方面客户却抱怨团队效率低。究其原因，是团队在处理技术债，并且做一些非业务性的维护工作，占用了新业务开发的时间。团队一味强调忙，但没能用客户能听懂的语言来说明并量化这部分工作。
我从敏捷的角度上推荐了一些工作方法，比如找合适的在线看板工具，让客户能容易的看懂当前团队的工作，建立多个渠道跟客户沟通，营造更好的透明度。任务分解到更小级别等等。
访谈结束后，团队非常认可我提到的问题和建议。 但是一周以后，我再来访问团队的时候，他们什么都没做，并且列举了一大堆困难，证明我推荐的方法虽好，但不适合他们，然后问我还有没有其他方法。
我知道团队在寻求敏捷帮助之前，也尝试过一些方法，但是都类似的浅尝辄止。并没有对方法有深度的学习实践投入。进一步调查后，我发先根本原因是因为客户虽然对团队有所抱怨，但是因为体制原因，没有更好的选择，所以团队并不担心客户不满意会导致自己失业。
这就是典型的"想解决"，但并不"渴望解决"的问题。
当人『渴望』解决一个问题的时候，会不吝投入时间，精力，资源。甚至会逼出些『急智』来。 当人只是『想』解决问题的时候，就会过度的计较投入。
敏捷是一套复杂的方法论，需要大量的学习投入，并且在正确的引导下，坚持半年到一年的实践，才能够达到某种程度的应用。在问"敏捷到底能帮我解决哪个问题"的时候，不如先问问自己"我是否足够渴望解决问题，以至于愿意付出如这样大的努力"。
敏捷能解决什么问题不重要，敏捷为什么这样设计很重要
清楚明白的答案，或许容易理解，不需要花太多时间研究，但于解决实际问题并没有什么卵用。因为凡是能解决一个非常具体的问题的方案，可重用性一定很差。即使是同一个问题再次发生，也可能会因为环境的变化，参与的人的变化，导致以前的方案不再适用。
Best Practice很多，但你要真统计一下复制成功率....
既然具体的解决方案重用性那么差，为什么我们还常说，"他山之石，可以攻玉"呢？如果简单复制对方的做法，大概率是要失败的。但是如果借鉴对方的做事思路，制定适合自己的方案，则大概率是要成功的。
与其呆板的将Scrum流程拿来重复，不如借鉴其思路 - 比如Scrum它设计了短迭代，MVP，user story，都是为了保证跟客户沟通的频率， 同时确保沟通的语言是客户看的懂的语言。
你可能做不了Scrum，但你一定能找到合适自己的方式，让客户跟团队频繁的出现在同一个场域里， 见面多了沟通就会发生。你也会有你自己的方法，将团队的工作转化为客户能轻易看懂的语言。
简单的重复的使用工具，或许在一开始能帮你解决某些问题。 但是在问题解决后，继续单纯的重复就会变成负担。
每日站会(Daily Standup)是为了创造一个场域，它的目的是增进沟通，暴露问题，互相支持，同时时间盒以及不讨论细节的约定，又在训练你关注会议效率。
假如团队成员之间，已经工作透明的，互相频繁沟通，互相支持，那么每日站会就变成了额外的负担。
理解了工具的设计原因和解题思路，才能灵活运用，不断的解决问题。
但是你如果理解每日站会设计的思路，比如为何使用时间盒，为何不讨论细节，你就可以知道如何去提高所有会议的效率。
在敏捷成熟度很高的团队，如果突然来了一个不常见的，有挑战的工作。或者新成员加入团队，那就可以启动每日站会，帮助新员工尽快融入。 但当团队重新渡过挑战期，每日站会又可以重新放回工具箱。
一个开瓶器，只能用来开瓶子。 但是如果理解了背后的杠杆原理，虽不见得能翘起地球，但是至少能贷款买房，融资炒股，打架的时候四两拨千斤不是么。
所以你是要获得一个偶尔能用的上的开瓶器， 还是想变成一个能够灵活运用杠杆原理的人？
这篇关于敏捷(Agile)工作方法到底能帮你解决什么问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
