“只要参与过一两个软件项目，就一定对书中介绍的情景深有感触，也必然会从中得到经验教训”这是《软件随想录》的作者Joel Spolsky对这本书的感受。
以下我也结合自己实际的工作体验对这本书中的模式场景说一下自己的感受：
模式“
玩的就是心跳”大概介绍的就是这样一种场景，在工作中永远都是紧迫的项目，在项目中永远都是紧迫的功能，项目组永远处于紧迫忙碌的状态中，试问这样团队怎样能有高质量的产出？
对于这种模式我深有体会，就拿我所在的研发部门引入敏捷开发的第一年来说，我们部门接手了一个大项目，先说说它的规模：分为web端，通讯服务器，客户端。模型：客户端<--->通讯服务器<--->数据库，web端<--->数据库，web端包含公共模块和对九个子产品的管理审计功能，客户端也会有九个子产品需要开发，其中还有分级支持，外围管理工具等等......。整个部门十几号人都参与进这个项目。起初，定的计划是半年完成框架的构建和四个子产品的研发并且推向市场，说心里话，除了上层外，估计大多数人都认为这是不可能完成的任务，于是随之封闭开发和加班几乎占据了我们的生活，很累，很累。但是半年并没能完成任务，我们的问题总结：前期有需求定位错误和技术选型错误。于是又把推向市场的时间往后推4个月，而这时对子产品的要求增加到完成六个，依然很紧迫，往往有这种情况，在敏捷中的一个两周节点平均两个人就要完成一个子产品（针对web端，通讯服务器，客户端的人员构成上来说），虽然有些子产品有基础，可是试想一下，在半个月完成一个将要推向市场的子产品？一个节点往往一个小组要承担自己任务的概要设计，详细设计，评审，编码，测试，于是大家按照任务分配拼命加班，而且节点与节点之间也很少有调整期，最后从完成度和完成质量来看，都不理想，于是紧迫的任务又得往后推，接着又是下一轮紧迫，而且即使在计划内，也会突然冒出其他项目的紧迫任务要某些人处理（通常都是推向市场的要求）。这种心跳玩的太过于频繁，但是效果并不好，通常会因为软件质量问题而阻碍推向市场，从我们大家的心理和身体状态而言也是种恶化和透支，虽然，项目在某些方面取得了成功，但是这种“频繁心跳”后的
代价就是让大家对项目的紧迫度产生怀疑？让大家对接踵而来的紧迫任务疲于应对!
怎么治愈这种“玩的就是心跳”呢，书中给出了这种建议：作为一个管理者要有方向，要有战略指导，任何组织内部都会遇上紧迫的任务。但是，不是所有的事情都是紧迫的，也不是所有的角色都要关心紧迫的任务。除非化紧迫为优先级和约束，否则，这种“玩的就是心跳“几乎不可能被治愈。
本文转自永远的朋友博客51CTO博客，原文链接http://blog.51cto.com/yaocoder/784153如需转载请自行联系原作者
yaocoder
