公司今年全面铺开Scrum开发流程，于是乎，从年初到现在，那是铺天盖地的培训： 请内部实施过Scrum的team；请美国参加过Mike Cohn同学培训的同事；请外面专业培训机构~~~多是多，但感觉缺乏系统的安排，不免显的有些乱。
上周就参加了一堂UPerform的培训，题为<User Stories, Agile Estimating and Planning> ,为期两天。要说对Scrum的理解有了质的提高，也谈不上，毕竟我们Scrum也跑了一两个月了，该了解的也都了解的差不多了。但也有些有趣的见闻，不妨记录下来。
- 关于讲师
培训讲师叫Vernon，美国人，但是个中国通，有个中文名字叫史文林。 我非常喜欢他的讲解方式，生动活泼，气氛活跃，并经常会作出一些美国式的夸张表情。 他和他的中国助手对话方式十分有意思： 他讲英文，对方讲中文，双方都能听懂~~~呃，其助手叫李国彪，网站上对其的介绍那是相当的牛逼哄哄，但是就现场其表现，以及这个原因， 感觉有些言过其实。 - 软件项目失败的原因
一上来就让我们每个人分析自己遇到过的失败的软件项目的失败原因。大家的箭头都不约而同的指向了"Requirement"， 看来，很多人都体会到这是软件开发中存在的最大问题，也难怪那么多方法被发明出来试图解决这个问题，如我们正在应用的User Story和Scrum。 其他列出的原因还有： Quality of design/code; Communication; Aggressive schedule; Risk management等等。 - 什么是看板
学到一个生产管理中的新名词：看板。它是一种根据目标拉动生产的管理方式。如果比喻成吃馒头,可以这么说,店家的馒头用一个笼子装两个,一个人如果拿一笼吃完了还要吃,就把笼子还给老板,老板又装两个送到你手上,如果吃完还要
吃,那又把笼子拿回去还给老板,老板就知道又该送两个给你了,老板没有收到笼子就不用给你送馒头,说明你还有得吃,你不需要再吃时,也不要把笼子送回给老
板,免得你还没吃完时老板又送来了
很明显，软件开发不是生产，是创造，是具有相当大的不确定性的，不适合用这种方法来管理。 - A pig with lipstick
有人问，是不是应该在每个项目的第一个Sprint用来收集User Story，并做出最初的架构。回答是这是Scrum-Fall开发方法，就是Scrum和Waterfall的结合，本质上还是Waterfall，就像a pig with lipstick还是只猪，而不是个姑娘，瀑布模型加上Scrum的形式，它本质上还是瀑布模型。 Scrum讲究勇气，敢于get start without certainty, 并在开发过程中不断学习、细化需求。 - 创新不一定是加法
在谈到Apple的创新时，李国彪同学提出了这一点。很是同意，很多时候，简单就是美，比如雅虎做搜索做了那么多年，但是其搜索框总是淹没在无数内容之中，google横空出世，给了大家一个简单的搜索框，大获成功：这就是减法创新。 - Scrum的困难：Courage， TDD, Clients
我提出的了一个问题，问他们在帮其他公司实施Scrum的时候，遇到的最大的阻力是什么。概括起来就是勇气：Clients不习惯这种密切参与的新流程；开发不习惯TDD的开发模式(他们采用了TDD)，没用勇气来接受这种变化。 - TDD至上
第二天下午又来了一位讲师，貌似比史同学还要Senior，他们都极其虔诚的推荐TDD，就像我给人家推荐《阿凡达》时那样确信：如果你还没开始用TDD，立刻开始用它，你会爱上它的！既然如此，虽然现在的项目用不着TDD，我自己也一定要试试这个方法了~ - 用Story point来估计task的好处
我们一般习惯用Story Point来估计User Story, 而用"Hour"来估计每个task，但是他们提出应该用Story Point来估计task，原因也相当令人信服： 一是你可以来检查你的User Story估计是否正确， 而Hour和Story Point则没有可比性； 二是每个人完成某个task的时间是不一样的，不能准确的反映出一个task的"工作量"。 虽然如此，我还是会继续使用Hour来估计task：我们习惯于此，我们用的系统Jira支持于此。 撇开抽象的Story Point，我们需要一种直观的数据来看待我们的工作。 - Don't push a sprint
如果一个发现无法完成sprint中所选的story，千万不要去"赶"工期，这必然会导致软件质量的下降。正确的做法是提前发现，提前调整 - 只要我们的Sprint Goal还是可接受的。 - Use the fucking wall!!!
有人问实施Scrum最好的工具是什么： 当然是墙了，把你们的backlog，burn down chart全展示在墙上，透明，方便、直观。 但是我怀疑除非重新装修，不然我们的墙肯定是不够用的。所以我们还会用Jira： 一是方便distributed team合作，而是方便管理层的巡视:) - Metaphor: Scrum和骑自行车
这是一个很好的关于Scrum的比喻：如果你打算骑自行车从a点行至b点，你是怎么做的？ 一是你肯定得明确你的方向大概在哪里， b点； 二是在你行进的过程中，你肯定需要不断的小幅度调整方向，以便实现你的最终目标，到达b点。 Scrum开发项目不就是如此吗。 - People ！= Resource
史文林同学非常反感把People称为Resource，这应该是广大外企的通用称法吧，说实话，我也相当反感这种说法，正如史同学讲的：什么是resource，就像toilet paper一样，用了就要扔掉的，可以随意替换的才叫resource。