最近和一些朋友交流如何启动敏捷实践的问题，我觉得在提供“How to do”的方案之前，先想清楚“What to do”。本人没有啥最佳实践，只有血泪史，也不想吐槽，只想和大家分享一些观点看法，下文是关于如何启动敏捷实践的一些思辨，希望得到大家的指点和纠正。
1、 “形”与“神”
对于缺乏经验的团队，实践应该先神后形，而不是先形后神。形指的是Scrum3355套路，神指的是敏捷实质，可以理解为沟通和反馈的高效、协同效率和交付能力的提升。
血泪教训告诉我，形式如果在一开始不能产生好的效果，会直接导致团队的实质性抵制，使敏捷实践走向夭折，或者在后续花费成倍精力去艰难扭转。敏捷推动者一定要先带领团队实现一些“神”的效果，再落实“形”，最终演变成由团队通过自我管理实践“形”，获得“神”。
敏捷推动者需要先结合团队的现状，用各种管理和推进技巧帮助团队落实Scrum的三个支柱“透明、检视、调整”，通过一段实践实质提高交付水平之后，让团队感受到变化，再慢慢走向Scrum的套路，才能使团队真正体验到Scrum3355的威力。休克式的直接切换成Scrum的套路，必死无疑。
凡是提出“Scrum很简单，先进行试点，各种会先开起来”的敏捷推动者，我认为都是吃亏太少的。
2、 “守”与“攻”
错误理解“守破离”会将团队带入“伪敏捷”。“守”的核心其实是“攻”。
“守”的过程是团队按照Scrum的要求去实践，不断的发现问题，不断的“攻”问题，而不是在不具备基本条件的情况下，仅仅盲目严守Scrum3355的形式。
敏捷实践要经过很久的“攻”才能使团队达到能“守”的水平。这个过程可以理解为敏捷导入的最初阶段，通常需要在教练的辅导下，在多个方面各个击破，解决障碍。
如果团队面临很多实际问题，使得计划会、站会、Review会、回顾会、梳理会都不能取得预期效果，仅仅遵守Scrum的形式，那么团队就进入了形式主义的“伪敏捷”。
以《士兵突击》许三多举例，他从入伍开始“守”，直到费尽千辛万苦，练废最佳教练（史金）之后，才实现了“守”，成为钢七连最优秀的兵。你还觉得“守”很容易吗？
3、 “说”与“做”
敏捷实践是“先做再说”还是“先说再做”？
在大家对敏捷大范围不了解的情况下，先大张旗鼓的宣讲、培训、洗脑，再直接进入套路实践，会在一开始就面临很多的质疑，大家对敏捷的理解必然差异很大，敏捷推动者需要反复解释、说明、安抚、甚至对未知的结果进行口头承诺。后面遇到的各种客观阻碍，都会变成“敏捷不适合我们”的理由，会给后续的实践造成很多不良影响。
在进行敏捷实践之前，要先梳理现有问题，先引导大家认清现实情况，再引导大家一起用敏捷的观点去解决克服，大家看到了效果，才会真正配合投入。
4、 “始”与“终”
一个迭代以计划会为始，以需求故事为始，以回顾会为终，以故事的验收为终，那么验收条件的确立属于哪个部分呢？
验收条件是为“终”服务的，对于PO来说，提出需求故事时，同时提供验收条件，才能够更好确认需求质量，才算是有质量的“始”。如果把这个作为计划会DoR的一部分，会有利于PO的进步成长，要“以终为始”。
同样，对于研发来讲，TDD是公认的提高质量，提高速度，提升效率的技术实践。在编写业务代码之前，先编写测试代码，两者同时交付。同样要“以终为始”。
以终为始是倒逼业务敏捷的良好方式，提出一个需求，务必提供验收要求。压力一定要传递到需求提出方。
昨天在某个群里面讨论这个话题，有位同学说，“领导提出一个需求，你跟他要验收条件，他会怎么说？”，有位同学回答说“你一下子就知道，其实他自己都没想明白，你要用需求管理的技术帮他做分析和拆解”，另一位同学回答说“我们领导的验收条件是：这个问题你要帮我想清楚来告诉我，你告诉我之后，我来决策”。这种情况下，DP哥含泪回答“凡是领导说的，都对。”
5、 “P”与“O”
在敏捷实践之初，被任命为PO的产品经理，有能力成为产品负责人（Product Owner）吗？他需要改变工作习惯，需要与团队一起梳理需求，并对他们进行拆分和优先级排序，还要尽量多的和研发小伙伴在一起。“负责人”代表着决策，代表着和实施者的对立，他会压力很大，他会很累，很孤独，特别是在拆解的时候，需要团队的支持和协助，这个时候要大家一起成为“Owner”。因此，当PO能力尚不足的时候，请不要从一开始就当成负责人（Owner），而是定义为需求的“牵头人”或者“牵头组织者”（Organizer），这样有利于他更好的开展工作，逐步成为“Owner”。所有，一开始的时候，“P”还是那个“P”，“O”最好先别是那个“O”。
假想的敏捷实践启动方案
DP哥坚决的认为，敏捷实践没法长期规划，没有标准模板，没有最佳实践，别人吹的牛皮只有参考价值，想复制是不可能的。
DP哥假想了一个二个月左右的敏捷实践启动方案。
启动方式：
利用一个大规模的长期项目，组建干净的全职团队，开始认真的敏捷实践
时间跨度：
（2-3个月、4-6个Sprint，以管理实践为主、遇到问题时考虑技术实践和工程实践解决）
What to do：
1） 从项目结果上，确保该项目的高效迭代交付
2） 在项目管理方面，符合敏捷项目管理的特点
3） 在项目推进过程上，使团队感觉到自我交付效率的提升
4） 从工作氛围、协同、环境、方式上，使团队感受到敏捷的特点
5） 使团队树立正确的敏捷及Scrum框架认知
6） 发现的组织及团队问题，得到领导层的认可和改善承诺
How to do:
看着办。没错，答案就是看着办。
