1. 一个敏捷实施的案例
背景1：
公司曾经尝试自上而下的敏捷转型，并邀请IBM专家进行长达两个月的交流。然而部分敏捷实践的效果差强人意，多个团队都反馈实施敏捷后效率降低，团队疲于奔命。最后敏捷戛然而止，公司上至管理层，下至普通员工，对敏捷讳莫如深。
背景2：
核心系统长达10年未重构，不堪重负，然而维护核心系统的团队成员全部流失
笔者转入新部门，被要求组建团队重构核心系统，时间紧迫，团队全是新人。
面对艰巨的挑战，笔者决定欺下瞒上偷偷实施敏捷，重构让客户满意的核心系统。
敏捷实施效果：（列举数字）
2. 瞒上篇
问题：重构是否必要？
通过MVP证明重构能够解决核心系统的非功能性问题：性能、稳定性、可扩展性、可维护性。
MVP可以是可工作的软件，也可以是一个业务模型、一篇设计文档、一幅UML设计图
问题：重构能否做完？
分解需求，被依赖的最重要，主要功能次之，不重要的功能不分解。
第一个月交付被依赖的需求，确保与其他系统的集成工作顺利展开。
第二个月交付主要功能，新系统交付使用。
不重要的功能甚至到第四个月才交付。
通过分解需求，不断快速交付让客户满意（ＰＭ，ＱＡ，其他团队，测试团队）。构建交付地图让客户和团队都能清晰看到进度情况，对交付更有信心
问题：重构做的怎样？
每周三、周五主动汇报一次团队概况，每次与pm沟通半小时，通过碰撞发现问题。
通过不断的试错，快速的收集客户的反馈，及时调整，逐渐辨清目标，确保团队在做正确的事
瞒上篇总结
目标管理
1、快速交付MVP，基于MVP讨论目标
2、聚焦价值交付，先交付对目标最有用的故事
3、持续不断的交付，不断试错，辨清目标
Alignment enable autonomous
确保目标一致，团队才有权利自组织
3.欺下篇
我第一次和团队成员合作，怎么确保合作效果？
强迫团队写设计文档，每周输出一个心得。
5个人参与编写设计文档，有2个后来成为TL。
总共只有20+个心得，愿意输出心得的都成为主力人员。
效果：挖掘团队的积极分子，通过积极分子引导团队，让合作的效果事半功倍。
敏捷实施底线：定义交付
问题：怎么定义交付？
现象：
1、不知道谁确认交付？PM、设计师、市场人员未必懂开发，同时交付确认方太多
2、多大的交付物比较合适？太大则开发周期长，太小则对设计要求很高
3、PO太忙，交付确认走过场，或者根本不确认
没有完美的交付定义，只有合适的交付定义
1、一个函数不能超过50LOC
2、每次交付不能超过300LOC
3、交付物至少有一个单元测试用例覆盖
4、交付物必须经过团队评审，在评审时，作者演示一个单元测试用例。
5、团队认可交付后，责任是团队每个人的
交付物满足INVEST原则，并设定为底线，坚决执行。
效果：
1、写完代码就组织团队评审，无需依赖某个角色，实现快速交付
2、频繁的评审，让需求越辩越明，彼此学习开发技术，团队的开发能力迅速提升，团队1/8的时间在评审，但是开发效率却翻倍。
3、每次交付都编写单元测试例，团队逐渐体验到自动化验证的好处，TDD莫名的产生，覆盖率高达90%
敏捷实施引导
问题：定义交付后，敏捷落地了么？为何团队实施的效果仍差强人意？·
现象：
1、团队闭门造车，团队内缺乏沟通，彼此不知道对方做什么，出问题只有某某能解决
2、团队互助氛围差，帮助别人对我有什么用，新人基本靠自学
3、统一团队中设计、开发、测试总是彼此干扰，工作大受影响
通过对问题现象的分析，笔者思考的解决方法是通过部分敏捷实践，来引导和活跃团队的交流氛围，让沟通越来越高效。
整个引导过程的突破口就是寻找团队中活跃的积极分子，日常工作中传递技能给积极分子，通过积极分子将技能传递到整个团队。同时将积极分子树立成榜样，引导团队其他成员向积极分子学习，带动团队氛围
实践一：迭代计划会议
迭代计划会议容易出现两种极端：过度沉闷或者过度热烈
保守人员习惯于上级安排工作，也不愿估算，整个过程讨论很少，会议很沉闷，更多是走过场。破局是通过询问积极分子（其一般思考很活跃），从而带动交流氛围,确保团队对交付内容的理解是一致的。
先让积极分子估算，从而带动团队其他人员的估算意愿。
热烈的会议是一次辨明需求的机会，但是过度热烈（一次会议开上3小时），则说明需求分歧很大，很可能没做好前期准备。可以将争议搁置，该需求优先级降低。（个人体会，3小时还没搞定的需求，很可能是非常复杂的业务，急着进行确认反而会适得其反，引起估算不准，返工等问题，以后团队对迭代计划会议的意义渐渐不再认可）
心得：准备几个非常有把握的需求，如果其他需求争议过大，至少能将有把握的需求顶上。（不明确的需求，无论优先级多高，都建议降级，除非你本身就打算试错）
效果：团队对交付物的认识趋于一致，走出承诺的第一步。
实践二：早、晚站会&半周报
1、TL倾听团队的工作，帮助解决问题，而不是布置工作
2、每周三周五统计好数据后，笔者会在第二天早站会表扬表现优异的成员，利用早站会引导成员重视交付数据
3、强迫每个团员站在中间面向团队发言，让团员重视早站会，培养团员自信心
效果：
1、建立渠道，让团队在日常工作中能了解整体工作情况
2、与团队的互动中，引导团队重视交付数据
实践三：统一团队
反思：统一团队为何干扰大？
现状：设计、开发、测试堆在一起，实际却在负责不同的需求，不同角色间的沟通要求很高，自然大部分情况下就是干扰很大
改变：上游团队主动协助下游团队
效果：测试团队执行了400个用例，发现了大量缺陷，研发和测试团队却相安无事
欺下篇总结
敏捷落地实践
1、培养种子，以点带面
2、建立底线，定义交付
3、通过日常交流，引导团队频繁交流、重视交付，通过不断碰撞和学习，逐渐理解敏捷思想
��R�Cuw
