敏捷推广过程中，记录一些同学的问题和思考，持续更新。

Q：为什么要守破离？

A：敏捷一开始推行的时候，很多团队并不是大家都能知道为什么要这么做。因为很多为什么是要经过大量的实践才能回答出来的，为了能让团队能迅速体验到敏捷的好处，这时候就需要守——先按照教练的方法、书上的方法去做，直到团队悟出了为什么，知道了为什么，团队就可以根据自己的情况调整实践的做法，这就是破的过程了。最后根据团队实际情况，确定适合自己团队项目的敏捷实践方法，通过回顾不断改进，这时候就是离的时候了。

Q：估算不准确的话为什么还要估算呢？

A：首先之所以是估算，就是因为估不准；其次估算其实是一个重在过程的实践，除了能给我们一个大概的工作量的结果，更重要的是能揭示大家的理解和所拥有知识的不一致，因而尽早的打破这种鸿沟；可以把团队成员心里的假想暴露出来，通过暴露假想，团队能发掘更多的细节和问题，这才是估算的真正价值。

Q：怎么区分做正确的事和正确的做事？

A：很多团队经常会有这样一个情况，大家在激烈的讨论一个技术问题，具体如何实现，但是他们却不知道背后用户的业务逻辑，他们到底在试图解决用户的什么问题。这些技术问题，在用户看来只是方案，也就是如何正确的做事，而团队实际要解决的是用户的问题，这个才是团队的初心，是团队的价值所在，也就是要做的正确的事。问题和解决方案之间是一对多的关系，因为有用户的问题，所以我们有软件的解决方案。解决方案往往面临的事技术问题，往往是我们的问题，而不是用户的问题，所以要时刻记得用户的问题是什么，不要沉浸于技术问题，而忘记我们究竟要给用户带来什么价值，解决什么问题。

Q：Scrum里有个TEAM的角色，TEAM里面是否还需要分岗位？

A：敏捷里的TEAM是跨职能团队，就是为了区别过去的职能团队，每个人只能做职能范围的事情。在跨职能团队中，每个人都可以做团队需要他做的任何事，每个人都应该有架构师的视角，每个人都应该有QA的视角，所以scrum里一般会把这些职责工作当做帽子，不会给团队成员打上固定的标签，你做什么就什么（don't label yourself,you are what you do）。

Q：怎么判断我们团队是否在做敏捷了呢？是否使用了scrum，lean，XP的各种实践就可以了呢？

A：敏捷宣言的第一句话：我们一直在实践中探寻更好的软件开发方法，身体力行地同时也帮助他人。是否敏捷，更加看重的是我们是否不断在寻找适合我们团队效率、产品质量、产品功能的思维和方法。各种实践只是帮助我们更好的达到这个目的，如果团队使用的方法不在常见的实践范围，但是总是不断发现新问题，并不断改进，那么就是在敏捷的道路上了，不用纠结各种具体的实践。但是这些总结的实践，之所以会被认可和推广也都是被证明在大多数情况下能更好的帮助团队敏捷化的，所以这些实践都是可以借鉴的。

Q：到底什么样的产品、项目、企业适合使用敏捷？什么样的适合使用传统开发方式呢？

A：凡是产品需求前期非常明确，并且业务类型基本没有变化的项目和产品，都适合传统开发方式，这种情况多见在军工，金融，航天、制造业中，这种失败成本高，其核心价值观是利用需求、计划的可追溯性、一致性，来达成对生命攸关和潜在重大损失项目的保障。凡是前期需求不明确，在开发过程中需要不断做演示，不断得到用户反馈，功能需求不断变化的情况，允许团队通过不断试错，迅速响应需求变化的场景，都适合更多的使用敏捷思维的工具和模型。但是无论哪种模型，沟通、互助、主动、责任、谦虚等工作态度在任何情况都是适用团队的。

Q：敏捷如何帮助我们控制成本？

A：并不是所有的项目都适合用敏捷，关键看我们最后想要达成的目标是什么？如果目标是看到某个产品在互联网用户中的增长率、产品反馈速度、那么敏捷可以非常适合。但是如果是成本控制，敏捷无法很好的准确估算，这个不是敏捷的强项。但是敏捷中的一些实践仍然可以帮助我们更好的交付，比如频繁的沟通和站立会议，看板等，这些和开发模式没有关系，这些依然能帮忙我们提升效率以达到成本控制的效果；

Q：QA和QC的区别？

A：QC是测试找到BUG，QA是预防产生BUG。QA不应该在用户故事生命周期的后半段才介入，而应该在一开始就介入，那么也就是我们常说的测试前移；

Q：团队中很多老资格程序员，每天千篇一律的coding，难免枯燥，如何让开发保持热情呢？

A：很多团队经常赶进度，枯燥的编码生活，要保持开发热情最重要的是让他们有成就感。在平日工作中能不断学习，每天都能看到自己的进步，周围同事对他的进步能迅速给出反馈，让大家在这个团队中能有更多的成就感这是关键。