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

采取的方案主要是3点：

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

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

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

Whenever you feel like criticising anyone, just remember that all the people in this world haven't had the advantages that you've had.

这是《了不起的盖茨比》这本书开篇的一句话，也是整本书给我留下印象最深的一句话。现实生活中要做到这一点，其实有点难度。当你想批评人时，大脑往往处于冲动状态，这个时候是不会理性思考的，根本不会去替别人考虑。批评别更多是一种个人情绪的宣泄，等发泄完了，大脑平静了，理性思考才会回归，这时，大脑才会考虑“he didn’t have the advantage that I’ve had”之类的话。并且为刚才的批评感到好后悔。

我经常就发生这种事，当对同事做的事不太满意时，我经常会说他几句，基本是脱口而出的，根本没有经过大脑。事后就会后悔：哎，这也不是什么大不了的事，好好跟他说不就完了吗，干嘛语气这么重呢？反思过后，下次同样的事情还是会发生。

所以，当你要批评别人时，首要的事不是想想自己比别人有优势，而是先闭嘴，让大脑平静下来后，再来处理。

今天陪儿子去医院做磁共振检查，门口放着一个意见簿，闲来无事，就顺手翻了翻，一共10来条建议，大概可以分成三类，一类是好评，比如感谢医生、环境很好这类的话。第二类是差评，骂医生没有良心等等。第三类是客观的提意见，比如建议开水机旁边放点茶叶，时间观念有待加强等。前两类属于情感的发泄，对医院改进服务没有什么意义。只有第三类有参考价值，至于医院会不会采纳，那又是一回事了。我特意留意了饮水机，旁边没有放茶叶的地方，而这个建议是去年10月份提的。

我们平时也经常开总结会，会上大家讨论的热火朝天，提了很多建议，然后。。。，就没有然后了。 PDCA循环里，A是最重要的， 但往往A最容易被忽视。 会议纪要就像医院里的“意见簿”，一直挂在那里，却很少有人问津。

要拍摄黑洞的全貌，得制造一个地球大小的望远镜，这显然是不可能的。科学家用了个取巧的办法，利用分布在全球8个地方的望远镜组，得到了部分黑洞的样本数据，然后利用算法还原出整个黑洞的形状。 问题是如何来判断算法的准确性？谁也没见过真正的黑洞，所以根本无法验证。就像画鬼一样，无论怎么画，都是对的。这次发布的黑洞照片，确实很像“黑洞”，符合大众的预期，但是不是真实的“黑洞”呢？这个问题就像“真的鬼长什么样”一样，永远没有答案。

怎样拍摄一张黑洞的图片这个视频介绍了拼成黑洞照片的算法，并给出了算法效果图

但这并没有解释明白为何这个算法是正确的，反而给人带来了更多的困惑。按照这个算法，完全可以随便弄些照片来，也能做出一张“黑洞”图。何必这么大费周折呢？

如有大神看到，还望不吝赐教！

经常有这样的感觉，一些事情如果自己没有去跟进，往往会拖好几天。我从开发那儿也很少收到主动的、有效的反馈。看下禅道上的问题，如果没有解决，哪怕花了一周时间，你也看不到有任何的comment更新，直到问题解决了，comment就是“已解决”三个字。我一直在思考这个问题，为什么开发如此的不愿意更新问题comment。因为我不是开发团队的直接管理者，不好以制度的方式落实下去。就算可以，我也不愿采用，在我的意识中，及时的更新问题状态是一个开发的基本素养。JIRA、禅道这些工具，如果仅仅是记录下问题，没有任何的解决日志记录，它的价值只利用了一点点，对我来说，这些工具是团队的知识库、沟通工具。问题的发生原因、解决办法、设计实现讨论等内容都可以在上面记录。但开发团队没有意识到这点，虽然我跟他们提了很多次。

要让团队有些改变，光靠说显然是不行的，首先，大家是不是都认可，有人就不喜欢写comment，你怎么办？其次，要有可操作的行动，不能指望大家自觉。我一直就有这个问题，就是高估了团队的自觉性，这往往导致事情半途而废。改变是很痛苦的事，很少有人会主动改变自己的工作方式。所以，从今以后，把“自觉”两字从管理词典中删除。

最近在负责测试，一共5人，目前的状况只能称为测试组，离测试团队还远的很，我应该想想做点什么了。