周三参加了敏捷社区主办的一个活动，主题是关于阿里健康团队的敏捷转型实践。两位老师分享了自去年11月开始转型以来团队取得的成效、采用的方案以及对敏捷实践的总结。我因为去的比较晚，只听了后半部分。整个分享给我印象最深的就2个字“价值”。 敏捷转型最终目的是交付更多的价值，如果只是遵循了一些所谓的敏捷实践，却没有在价值上比传统方法体现出优势，那就是为敏捷而敏捷，这不是敏捷的本意。分享老师也屡次提到，在转型过程中，不会强制要求团队按照敏捷的方式去做，没有站立会？可以，没有TDD，也OK。 只要你能完成预期的目标，用瀑布式也可以。 阿里健康有一个优势就是有几个团队同时在做敏捷转型，总有团队会去尝试下一些敏捷实践，然后发现效果不错。其他团队看到了，也开始尝试，最后完成转型。整个过程是效果驱动的，当然这中间少不了敏捷教练的培训、指导。

采取的方案主要是3点：

1. 透明过程、获取基线 软件开发中最遥远的距离，是开发与设计对业务的认知偏差。个人认为这种偏差是导致团队价值交付能力弱的根源。 阿里健康开发与设计的人员比例是10:1，如果按照传统模式来做，价值交付的瓶颈就在设计上。问题是最终的锅大家要一起背。作为开发，你怎么办？是等着被设计连累，还是主动帮助设计，尽早开始开发，最后大家一起拿奖金呢？ 当然是选择后者了。 阿里开发团队会安排一个人负责某一个功能模块的交付，称为Feature Owner。这样大大缩短了开发与设计的认知偏差，避免不必要的返工，缺陷率也会降低不少。
   建立度量指标也是保持透明的重要手段，指标如何来选取？还是要从问题出发。比如当前的问题是未能准时交付，要实现准时交付的目标，可以采用累计交付偏差这个指标。同时还要考虑REAL原则 Relevant、Easy to collect、Accurate、Least side effects。因为数据的采集是个日常的工作，一不能占用团队太多时间，二必须要方便，否则大家都不愿意去录入数据。

2. 建立反馈环、自驱改进

3. 立体式辅导、赋能团队