百人团队敏捷转型日记 第三集 敏捷实施过程中几个拐点

1 站立会 
每天早上几分钟的站立会，最浅显的影响就是，基本上没有人会迟到了。 
团队从最简单的看板开始了改变。 
2 新鲜感的消失 
大概过来两周以后，看板上的便贴开始出现更新不及时，趋于形式化。 
3 只能靠奖惩规范？ 
新制度的推行，往往需要奖惩规范来约束。这显然起到了一些作用， 
但没有解决根本问题。起初，个人工作周报、小组周报、看板任务，存在着重复工作。 
4 减负，只保留有价值的过程 
后期，引入了SCRUMWORK工具。并对过程进行梳理，取消了看板，只保留站立会。 
团队已经养成习惯，奖惩规范也随之取消。 
5 不同的声音 
因为团队整个产品线团队过多，起初版本管理组统一管理，每个迭代是面向整个产品。 
这带来了一个困扰，有些项目需求更新快，有些基础性的平台需求并没有这么多。 
但是每个迭代都会影响所有的项目，这导致了一个问题，所有人都感觉节奏太快，压力增大，且整个系统的频繁更新，也会导致系统存在不稳定的风险。对客户来讲，就是你们一直在更新，一直在打补丁，就很少有个稳定的时候。工程施工人员也疲于更新。 
6 合久必分 
针对子项目的不同，分别对待，成了版本管理必须考虑的问题。这好比从中央集权变成了分封制，针对需求更新缓慢的，允许其更长的更新周期，并接口向下兼容。这样各个项目之间可以解耦，需求更新较快的项目，也不会受到限制。 
版本管理组从全权掌控变成了一个协调者的角色。确保各项目在一个大的版本内自由更新，不受影响。同时，每次更新版本管理都会有记录，从而实现对上线版本的可跟踪。 
7 如何应对团队人员流失？扁平的优势体现 
扁平团队的优势，尤其体现在当有一部分员工离职时，因为团队成员对自己的项目所有业务都或多或少的整体认识，且模块结对，互相评审，在团队内已经成常态。当有部分成员流水后，不会对整个项目造成过大影响。

微信交流群：