几天前，我们在讨论一个话题：为什么有些软件项目令团队成员体验非常差？

我们一致的结论是：比起忙，往往更可怕的是乱。

一旦乱了，项目的节奏感被打乱就会进入恶性循环。越乱越忙，越忙越乱。

治理"乱"局

我曾被丢到不少混乱的项目中，最大的感受是，良好运转的项目千篇一律，而混乱的项目有各种混乱。

这里举几个会产生混乱的例子：

• 产品经理总是希望榨干开发团队任何一点弹性，对于敏捷项目来说，尽可能在迭代封版前塞入新的需求，且需要赶在一起上线。
• 不对业务方案进行充分评审，没有前置的预研、技术方案阶段。
• 上一个迭代挤压欠债，导致后一个迭代的开始时间延迟，一直都处于被动状态。
• 好不容易赶上了一波，超前完成任务，发现后续的需求没有准备好，团队开始空转。
• 被产品经理或者老板催促着快速上线，不用过多考虑设计、质量，仓促上线后大量时间被用于调查问题、解决问题、修复用户数据。
• ……

这样的例子非常多，总结下来往往可以总结为一个原因：团队的节奏被打破了。 在收集一些开发人员的反馈时，项目运行平稳、有节奏往往是对工作状态非常高的评价。

想要将团队重新拉回节奏上，往往需要像人体感染病毒后的反应，必要时可以"休克"一下。

一个永远都在延期的项目，相当于奖惩机制全部失灵——毕竟反正做不完，也就那样儿了。破罐子破摔，没人会再想加把劲争取按时交付。

最好的做法是，根据现有团队能力重新定一个能够得着的目标，保持克制，绝不塞活儿。重新设定目标后，再优化整个工作流程中不合理的点，让团队赢一次。

如果团队能赢这么一次，那么领导或者老板就会归因到这些改革点上，并具有信心继续优化工作流。

迭代日历

为了构建更好的工作流，纪律是非常重要的一部分。

敏捷团队中的纪律，不是说早上几点打卡上班，而是：

约定好的事情，一定要在既定的时间发生。

这件事情极为重要。

高速运转的团队就像一套发动机引擎，关键零件通过齿轮和其他零件传递动能。

如果该发生的事情可以随意推迟，那么团队会很快溃不成军，越大的团队这种效应越明显。

如果能保证在迭代前一周准备好业务方案，那么就会有一周时间进行技术方案设计，在技术方案设计的过程中，业务方案有任何问题也可以即使调整，且影响范围比较小。

对于敏捷项目来说，所以我们往往需要准备一个迭代日历，并设定好会议提醒。

我之前也讨论过类似的话题，这里给出一个迭代日历的例子：

团队习惯培养

团队习惯的刻意培养也是构建团队工作节奏的重要手段。

培养好团队习惯后，整个团队会按照设定的方式、节奏运行下去，甚至管理者自己如果破坏了节奏和规则也会被团队自发纠正。

所以有时候自组织团队是一个伪命题，没有建立团队习惯前，谈自组织是非常不负责任的做法。所以《老子》的无为思想的前提是有为，即制定流程、培养习惯，然后则可以让团队自由运转。

下面这些团队习惯都可以刻意培养：

• 遵守迭代日历的固定工作时间，按时完成业务方案、技术方案、站会、代码检视等所有敏捷活动的习惯。
• 会议纪要和知识库的维护习惯。
• Tasking 和任务分解习惯。
• 主动评审的习惯。
• 记录架构或者技术关键决策的习惯。

在没有培养起团队习惯之前，谈自组织基本不可能，而培养出来一个具有良好习惯的团队，自组织就变得自然而然了。

甚至可以参考相关资料对新的团队进行习惯培养培训，在海外有很多类似的资料和教程，例如网站 https://www.newteamhabits.com/ 中提到了从不同角度如何培养团队习惯。

参考资料

[1] A typical 2 week Sprint calendar https://agilebatman.com/a-typical-2-week-sprint-calendar-60304478651b

[2] The New Team Habits https://www.newteamhabits.com/