1.1 时间线
这个项目的目标是打算到2011年早期，就能让瑞典所有警察都使用。开发工作大约从2009年9月开始。第一个生产版本（试点）一年后发布，然后是每两个月发布一个更新版本。
项目团队在2009年第三季度的最初规模是10人，2010年中期扩大到30人，然后到2010年第四季度的时候规模翻倍，达到60多人。
关键的里程碑是1.0版（向真正用户发布的首个试点版本）和1.4版（向全国发布的版本）。当然，PUST系统在以后的多年时间里会继续改进，发布更新版本，所以1.4版绝不会是最后一个版本。
或许很多敏捷开发人士会说一年才发布第一个版本似乎太久，但是与类似复杂度和规模的其他政府项目相比，这个时间已非同一般地短。曾有类似的政府项目开发了长达七年之久才发布第一个版本！而且我们每两个月都发布更新版本的做法也不寻常，很多政府组织通常一年才发布一两个更新版本，我们甚至都在考虑每个月都发布。
小乔爱问：为什么频繁发布？这样成本岂不是很高？
的确，每个发布版本都有一定的固定成本。但是每个发布版本都是了解真相的最佳时刻——我们这时才能了解产品是否与用户的需求契合！两次发布的间隔时间越长，我们在代码中嵌入的缺陷和错误假设就会越多。如果发布频率高一些，补丁小一些，每个版本的问题和风险也就相应降低了许多。
所有这些因素——发布周期短以及项目范围迅速扩大——都成为组织和开发流程需要快速改进的动因。
这也是我作为教练参与到这个项目中的缘由。
我从2010年12月到2011年6月期间参与了这个项目，每周在项目上的工作时间大概是两到三天。我的工作重点是将精益和敏捷原则投入实践，帮助开发团队制定最合身的流程。这就是本书要为你讲述的内容——我们做了什么、遇到了什么问题、如何处理这些问题，以及我们得到了哪些经验教训。这一段经历挑战性极强，却也乐趣无穷！
不过，需要牢记的一点是……
这本书基本上是项目流程2011年6月时的一个快照。精益流程一个最重要的特点就是不断发展改进。有时我们发现了更好的解决方案；有时昨天看上去相当不错的解决方案今天就会带来新问题；有时环境变了，迫使我们做出改变来适应新环境。
所以，等你读到这本书的时候，我们的项目可能已经是另一副模样了。