一、什么是敏捷

介绍敏捷的知识体系、敏捷宣言、以及敏捷原则。

1.1 敏捷树

敏捷全景

敏捷最开始的提出，是在2001年制定了敏捷宣言，是一套价值观。有了价值观，然后社区认同这个价值观的人会提出符合这个价值观的实践。相当于敏捷方法论是开源的。是一套基于树根能不断生长的方法论。

当‘术’不足以解决客户的复杂问题时，我们向‘法’去寻找答案；或者更复杂的问题，‘法’也没有答案，那么就向‘道’去寻找答案。

1.2 详解敏捷宣言

1）持续改进：1⃣️敏捷有没有checklist？没有，如果有的话，也就不需要敏捷教练了；2⃣️怎样才算是敏捷了？敏捷是进行时，持续改进。

2）好的团队，身体力行的同时也帮助他人，建立协作的团队文化。敏捷转型不仅是流程和工具，更重要是人的问题。比如去团队做赋能，但团队气氛紧张，专门用2周时间培育团队的信任关系；每个人专注于自己的职能，我不管总体目标，只管我的这部分没有出错。例子，一个人挖坑、另一个人埋坑，原因是放种子的人请假了。是可以在僵化的组织文化中构造灵活的团队文化的。

3）人体与交互胜过过程与工具。注重人和沟通。1⃣️现在的商业软件开发已经不是由几个天才来决定软件的成败，而是基于上百个人的协作，这种协作效果更多影响了软件开发的成败。可以说，软件开发现在已经是社会学了。2⃣️尊重人，和流水线/螺丝钉的思路有很大区别；软件管理思想和传统工厂的管理思路很不同。3⃣️scrum价值观中的透明，比如用户故事需要经过充分的沟通、透明。

4）可用的软件胜过详细的文档。1⃣️区分沟通用的文档和用于知识沉淀的文档。格式化的文档更适合索引，更适合作为知识沉淀，为了合规与知识回溯；沟通文档更适合图像，比如给开发一个2000页的文档，效率很低，但如果是10张图，那么更容易沟通。所以回答是否要写文档的问题，需要看文档是用于沟通还是用于沉淀。2⃣️可用的软件指的是每个迭代都需要出一个可用的软件，这是开发进度文档无法替代的。传统软件开发中很多软件都是在集成的时候遇到问题，敏捷可以实现快速响应，其中的依赖之一就是每个迭代都需要出一个版本，一个可用的软件。3⃣️现在的软件复杂度更高，无法在每个迭代纵切一个可用软件；因此需要重新考虑可用软件的概念，根据企业架构定义可用的软件。

5）客户协作胜过合同谈判。1⃣️只有跟客户建立信任关系，才能建立协作关系，需求才能稳定，需求稳定了交付迭代才能运行起来；这需要软技能。2⃣️合同谈判是传统的fix bid，重点在于风险转移，比如供应商管理，我只要结果，中间的风险我不管，这种背景下很难实现敏捷。

6）响应变化胜于遵循计划。1⃣️敏捷是有计划的，scrum计划的目的是让团队每个人知道什么时候做什么事情；传统的PM，只有PM一个人知道所有的事情，结果就是每个人都等着PM来催自己，并且只专注当前的事情，每个人没有整理的whole picture；scrum就是让每个人都知道周一开IPM。2⃣️响应变化不等于你要啥就给啥。响应和给结果是两件事情。响应在于下个迭代可用综合考虑这个需求。

7）尽管右项有价值，左边更有价值。也就是说当左右两边没有发生冲突的时候，我也会关注流程、文档；但是当发生冲突时，以左边为主。

2. 迭代

快速迭代迭代的是什么？我们总说2周一个迭代，这么说的时候其实是偷换概念。我们要迭代的是产品，不是时间。同样的，频繁上线不是为了上线而上线，而一定是有用户可以看到的东西上线才有意义。

做系统很多时候就像做个冰山，大多数都在水下，只露个尖尖在水面上。但是如果一个系统在一个迭代内做了很多水面下的事情，然后做了个上线，给客户花了一个小时做了个showcase，这一个小时和这次上线的意义是不是对于客户来说就是浪费了一个小时和积累了更多的怨念呢?

如果要做到快速迭代，需要的是将需求纵向的切分，在每一次迭代中能够让客户看到水面上的尖尖的一部分，这样他们才能够针对性的给出反馈，而不是闭门造车，将冰山下的一切准备好了之后再去做水面上的部分，不然这样的敏捷和瀑布除了多了一些繁琐的流程以外又有什么区别呢？

3. 敏捷与形式

比如Retro上大家做不到畅所欲言，私底下又吐槽项目，这样形式化的Retro我觉得反而是浪费大家的时间。    

比如25人的团队，15分钟的站会上，大家按照流程更新了昨天今天，但很少有人在站会上提出问题/blocker或者求助，这样的站会意义还大吗？