本次社区活动的第二大收获是开始对Scrum重新审视。

在以往印象中，Scrum是一个软件开发框架，PO是业务人员代表，开发团队是开发人员代表，为保证软件开发不偏离轨迹必须让开发人员和业务人员保持协作，避免一边独大。所以在Scrum框架中会严格规定几个角色的职责范围，PO用故事来描述业务价值，并有权分拆故事及排定开发的优先顺序；开发团队则在计划会上估算故事大小给PO提供反馈以便排定计划，再在随后的Sprint冲刺中实现故事。而ScrumMaster则在PO和开发团队之间起规则维护者的作用，保持软件开发过程中业务导向和开发导向的平衡，同时也作为屏蔽墙以避免团队受到外界过多干扰。

本次活动却让我对Scrum有了些新感觉。

全国组织者活动第一天，Bob让各个参会者随意提出话题，并自行分组，然后各组内部推举PO和SM，以一个半小时一迭代的频率在一天内完成三个冲刺，每个冲刺成果都要进行当众演示。纯粹的话题讨论，又不是软件开发，这也能用Scrum？

再往后，Daniel的紫色CSPO课堂上，又一个新提法出现了，PO不是Product Owner，而是Problem Owner？我突然意识到自己以前对Scrum理解存在很大误区。Scrum框架应是一个问题解决协同框架，而不仅仅是一个敏捷软件开发框架。正如前面Daniel谈学习时提到的，学习一开始面对的是Unknown Unknown，先得弄明白问题是什么；然后再面对Known Unknown，去解决问题。这里第一步对应PO职责，后一步对应解题团队（开发团队）职责。为什么PO一般只能一个，因为世界上有无数问题，不同人的问题选择可能完全不同，为避免问题无限发散，我们需要利用人的个体特性将之约束为一。为什么解题团队可以多人？因为虽然针对同一问题可以有无数解，但时间盒及反复冲刺迭代可以控制我们总能把解法收敛到一些特定项上并为问题解决服务。至于ScrumMaster，这个角色存在的目的是为了有一天能够消灭他自身。因为PO和解题团队精力都放在问题上，往往会忽视他们在配合时的协作方式是否最高效，这时，他们需要一个守望者，给他们以及时的提醒和指引。当整个团队都已经达到传说中最高的成熟境界时，守望者就可以归隐了。

当想清楚这点，一个新想法产生了，自己身边那些非软件开发团队，比如独立的测试团队，真就不能从Scrum中受益？自己以前思路太狭窄了！

Scrum的第二项触动是对时间盒（TimeBox）的感受。以前，我们在团队中尝试Scrum时，一般选用最短一周，最长四周的Sprint周期。这次突然发现迭代周期竟然是一个半小时！？第一反应是，这么可能？相较于我们选择的话题：“如何在组织中引发敏捷变革”。这个时间盒小得可怜，能够有什么用？很有意思的是，一天三个迭代下来，却突然发现，比诸我们想要的东西，这迭代时间是太短，但正因为时间短，大家反而更珍惜时间，更想在时间过完前给出尽可能多的产出，于是所有人都把精力聚集在如何避免时间浪费上，结果还真获得了远远超过预想的产出。短短三个迭代，我们小组成员从不认识到熟悉，把一个宽泛的话题目标收敛到几个相对集中的点，还统一了团队工作规则，协调了彼此的行动步调，得出一个问题解决框架并绘图输出，最终还引发自己对本组话题更深一层的思考。非常奇妙！时间盒的价值不在于时间盒控制下我们一定能有多少产出，而是，在约束之下，整个团队都意识到时间宝贵，互相提醒不把时间浪费在反复思考纠结上，更关注行动和配合，这样就更容易产生更多的收获。而且，有时间盒约束，我们总能保证在行动代价在可接受的范围内，这也能够更好的控制成本和预算。

第三项收获是对跨职能和Sprint冲刺的再认识。什么叫跨职能？不是说你啥都能做，而是说，此时此地我们全队都在向这目标冲锋，你能帮什么忙就尽量去做点啥！如果端茶倒水递笔送纸能够让主攻队员更高效的的出成果，这也是帮忙，这也是跨职能！同时，封闭的冲刺也让我们更好的全力投入当下！当全体成员为同一个目标全力冲锋时，团队感就油然而生，这是拉近团队成员距离的最快途径，是打造好团队的摇篮！更不用说冲刺成功后的喜悦！相反，不封闭目标，或者让人20%时间投入这，20%时间投入那？Oh！My GOD！单调乏味的流水线工作啊！

最后，还有什么收获呢？回顾！那天的咖啡真好喝！那天，头两个迭代时，我们总是太想有一些输出，太想向外界证明我们做了什么，结果产出虽多，但这真是最有意义的么？如果我们从现在开始，多关注快乐呢？所以，冲刺结束后，整个团队都到星巴克去了，一起坐下来喝杯咖啡，轻轻松松的回顾我们一起走过的路，想想我们后面要怎么配合才能做得更好，怎么才能更快乐。欣赏式探询真是好东东！！