敏捷的关键点:时间如何平衡的艺术

　　敏捷，会提到一个典型的实践，时间窗(timebox)，这个实践我们做的如何呢?

　　有时候会听到这样的声音，我们敏捷了，甚至说超敏捷了。我们没有专职测试了，开发同学自测保证;我们每天有晨会，我们有单元测试，我们有持续集成等等。深入一问，你们的交付周期或交付频率是?会得到一个让你想不到的回答，没有固定周期或频率。有时1周，有时2周，有时项目大了1-2个月。

　　敏捷的典型实践中还有，持续稳定交付价值、团队自主性调整适应、快速反馈机制，如果缺失了时间窗这个基本的典型的实践，其他的实践如何做?

　　关于交付频率，关于节奏，你会听到的回答：团队新人多，团队能力不足或产品特殊，所以无法达成周期固定，往往只能通过瀑布或者没有固定节奏的迭代或迭代分化为开发迭代与测试迭代等方式来补足，找了一个规避措施而不是解决根因的方法，造成的局面就是其他相关实践的有效性大打折扣或失效，从而认为敏捷没有效果或者衍生出具有特色的项目流程。时间窗这个实践，我们真的无法完成吗?我看不见得，是我们不想去适应和改变，固定思维在作祟而已。

　　持续稳定交付价值：因为时间窗(TimeBox)的实践前提无法达成，貌似我们可以做到“持续”、“稳定”的交付啦，甚至每天都可以交付、发布。实际上，每轮迭代的完成不是真正意义上的完成，心理预期总达不到;随着需求的变化，发布时间变得不可控，延迟、bug多等问题出现。导致管理者、开发、测试同学信心不足。

　　团队自主性调整适应：多好的一个实践，也是围绕时间窗这个实践进行的。如果时间窗这个实践做不到(不管是工作量超标、工作流存在浪费，还是能力不足造成的质量问题等原因)，如何调整适应到大家默契的程度，就成了团队的大问题;或快或慢、或紧或松的方式都会导致团队成员的吐槽，一旦不好的声音出现，团队就会遇到大麻烦。通过小步快跑，稳定的节奏，让团队成员知道什么时候该停下来，磨磨刀，然后继续砍柴。达到磨刀不误砍柴工，那时就是团队上路的时刻。

　　快速反馈机制：以上几个关键性特征前提的不满足，导致本实践特征的优先级被弱化，为什么这么说?持续集成的实时(提交)构建进入不了团队的重点工作、回顾会议取消、状态墙的弱化、结对无法持续开展、阻塞的事务得不到支持、资源抢夺式推动等等现象，促进问题快速反馈的功能都被其他更重要或更高优先级事务给取代了，忘本后只记得以上动作需要执行时被动的动一动。

　　面对时间窗，我们如何调整?

　　1.如果开发节奏过于密集，你会精疲力竭的。一般来说，当与其他团队合作时，你需要减慢开发节奏。

　　2.有规律的开发节奏，会让你有时间和精力去发现问题，并找到解决办法，或者暴露到你的团队中借助集体的力量解决问题，而不是因为赶进度而总是用临时方案解决问题。

　　3.以固定、有规律的长度运行迭代。也许刚开始你要调整迭代的长度，找到适合团队最舒服可行的时间值，但是之后就必须要坚持。

　　4.不要搞的经常加班。

　　5.在每天结束的时候，测试代码，提交代码，没有残留的代码。

　　6.就像是减肥一样，一点点的成功也是一个很大的激励。小而可达到的目标会让每个人全速前进。庆祝每一次难忘的成功。

　　最典型的节奏就是迭代周期，例如在scrum里面，就是一个sprint的周期，一般是1到4周的时间。不管你的迭代周期是多少，都应该坚持——确保每个迭代周期的时间相同很重要。运用有规律的开发节奏，会更容易达到目标，并确保项目不停的前进。

　　理想的效果： 开发过程有一致和稳定的节奏。编码，测试，代码review，持续集成，然后发布。 如果知道什么时候开始下一个节拍，跳舞就会更加容易。

　　综述，我的观点：没有固定的研发节奏千万别说自己敏捷了。因为这个时间窗是我们进行调整、进行适应的过程;暴露、解决问题的最佳闭环;通过团队成员的快速反馈让团队更健康，通过稳定持续的交付，让用户的反馈更快速，让我们的产品更健康。

　　时间窗，坚持用，更健康。

原文转自：http://kan.weibo.com/con/3537019464842462?_from=feed_wenzhang