如今，我们正处于一个颠覆性变革丛生的乌卡时代，我们周遭的世界正变得越发难以理解。乌卡（VUCA）时代的特点是，Volatitily：事情变化非常快，Uncertainty：我们不知道下一步的方向在哪，Complexity：每件事会影响到另外一些事，Ambiguity：影响的方式和关系还不明确。

互联网及人工智能等技术加速了乌卡化的进程，然而，伴随资讯和知识的泛滥，人们深度思考的时间越来越少。我们被大量的日常工作推得团团转，疲于应对各种突如其来的变化，很难静下心来思考问题。这导致我们处理问题的带宽越来越窄，绝大多数时候只能靠过往的经验模式做决策，形成一种被强迫的条件反射式浅反应模式。一直这样下去，我们就会越来越看不清未来，也越来越看不清自己，很有可能迷失方向。

在乌卡时代，当旧有的问题解决方式和决策方式不再奏效，甚至会陷入“越解越乱，越扑腾死得越快”的尴尬境地时，我们该如何去调动深层智慧，不被问题表象所惑，跳出现有认知模式的束缚，去看到全新的解题思路呢？

一场认知的操作系统升级今年5月份，我有幸参加了Ｕ型创变的基础课程PFP，近距离领略到Ｕ型理论魅力的同时，也让我对这个问题有了全新的认知。简单来说，U型理论是支持我们认知升级的一套方法论框架，可以说是一场认知的操作系统升级。近两年，据统计全球有185个国家，100000人参与了u.lab慕课的学习。在u.lab的调研当中，60%的人认为U.lab的学习让他们眼界大开，33%的人则认为改变了他们的一生。在社会层面取得这样的效果，和全球各地自发的u.lab线上线下社群密不可分，而“教练圆圈（coach circle）”无疑正是U社群中不断涌现的群体认识升级的秘密所在。

今天，就让我们从这个U型的核心流程＂教练圆圈＂说起，来个管中窥豹，看看这个在＂政商社学＂各界领导者中产生广泛影响的U型理论，在乌卡时代会带给我们什么样新的启示？

教练圆圈*如何撬动认知升级？

认知，几乎是人和人之间唯一的本质差别。大家都知道认知升级的重要，然而谈到如何去做到认知升级，却发现每个人都经历了不同的路径，或顿悟或渐悟，大多是可遇而不可求。我们中的绝大多数人，都很难通过自省来看清自己的行为模式和思维盲点，要想认知升级，清晰的自我认知就是第一个难点。

而教练圆圈，正是帮助我们提升自我认知的有效途径。更难得可贵的是，这种途径并不是虚无缥缈的心法，而是可落地可遵循的流程方法。在PFP课堂上奥托说，这个流程已经在实践中做了上千个真实案例，流程中的每一个细节都经过千锤百炼。

简单来说，教练圆圈就是一个小组对话的流程（Process），帮助我们调动集体智慧，从一个全新的认知层次来共同寻找解题思路。教练圆圈的目的并不仅在于解决一个特殊的问题，而在于以此问题做一面镜子，让每个人都有反思和觉醒。实践下来最大的感受就是，我们明明在讨论别人的问题，可是在结束的时候，每个人都从中看到了自己，得到了自己的收获。

教练圆圈*怎么玩

关于教练圆圈中的案例诊断流程，你可以在下面这段6分半的视频中，得到奥托详细的指导和演示。你所需要做的，就是找到一个4-5人的小组，开始第一次尝试（各个城市的u.lab社群是不错的选择，当然你也可以选择重新组建一个教练圆圈）。

你可以按照下面的流程开始：

（2分钟）选择角色：确定案例提供者和计时员
（15分钟）案例提供者陈述意图：包括你正面对的关键挑战和问题是什么？其他人怎么看待目标的状况？什么是你想要努力创造的未来？你需要哪方面的建议或帮助？
（3分钟）静默：将你所听到的与自己联结，试着感受一下，有哪些图像、隐喻、感觉、姿势涌现上来？
（10分钟）镜像反馈：互相分享有哪些图像、感受、姿势浮现上来。案例提供者对自己所听到的内容进行陈述。
（20分钟）生成式对话：所有人反思案例提供者的反馈，然后共同探索这些反思如何可以支持其对目前的情况和经历产生新的视角。
（8分钟）结束语：每个人轮流发言，然后案例提供者发言，对于目前的情况和下一步方向有哪些新的看法？互相表达感谢。
（2分钟）写日志：每个人写日志，记录自己学到了哪些？

教练圆圈中的这七步，其实就是一个典型的U的过程。

不同于从问题到解决方案的直线历程，在U的指引下，我们会经历一个下潜的过程，其中的第三步（静默）和第四步（镜像反馈）是取得认知升级的关键。

“静默”与“镜像”是认知升级的关键

在我们还没有确定什么是真正的问题之前，凭过往经验给出的建议很可能就是在误导当事人；而且由于彼此不在同一个频道，很容易变成鸡同鸭讲，吵成一团，谁也听不清谁要说什么。事实上，大多数时候，当我们在听别人的问题时，脑袋中一刻不停地盘旋着各种声音，”这个问题我早就遇到过”，”我跟你说，我要是你我就这样”，”这就不是个事儿，有什么大不了的”，”你这样肯定不行，会出大事的”……在结束案例陈述之后的3分钟静默，就是让那些旧有认知下产生的评判之声、自我表现和给建议的冲动逐渐淡化下来，让我们真正开始关注到这个问题带给我们的内在体验。事实证明，这一步非常关键！在PFP课程我们小组的案例访谈中，3分钟静默之后，小组的“教练们”产生了一些非常有意思的图像和隐喻：

有人描述就好比鱼刺卡在牙缝中，开始时只有隐隐的不舒服，尝试了很多种方式都没能弄出去，到后来整个人都不好了；有人感觉到自己的心像是被什么东西压着，胸中沉甸甸的，很想要逃开；有人看到了一个囚犯被锁链吊起双臂的画面，很想挣脱却又无力动弹分毫。

这些每个人与自己内心深度链接的画面、下意识的感受和身体姿势，就像多棱镜一般从各个角度，把案例提供者自己也未必完全意识到的内在状态投射了出来。 道德经有云：“至虚极，守静笃。万物并作，吾以观复。”只有我们去掉自身对世界认知的各种主观评判，达到空和虚的状态，才能够接受足够多的信息用以分析事物变化的真正规律；也只有这一步“静”字功夫真正做到位，我们才能与人为“镜”，观照出问题本来的实相。

共同开启一个更大的“洞见”

静定生慧，经历了这个U的下潜过程之后，真正的生成式对话就自然流动起来了。图像、感受、身体姿势的彼此看见，让我们链接到了这个问题的本源，它不再是一个人的问题，它彻底成为了我们的一部分。现场不再有旁观者，我们成为了案例提供者的另一个分身，有着同样的感受，有着从某种层面上来讲，共同的经历。我不再是小我的观点，当每一个“我”从小我的认知局限中挣脱出来，我们就共同看见了一个更大的视角，也共同开启了一个更大的洞见。你正在面对的艰难情境和身处其中的无力感，试问我们中的谁，没有经历过？你认定为原因的那个人或事，是带给你无力感的真正原因吗？你想要的到底是什么？你在努力挣脱的到底是什么？是逃离？还是坚守？你可以逃到哪里？每一个问题，都是在一次又一次，叩问所有人的内心……我们已然被牢牢地绑在一起，以一种我们尚不清楚的方式。从更高的维度去看，一个人，一个家庭，一个公司，一个国家，一个地球，这些大大小小的系统，以一种我们并不清楚的“乌卡”的方式相互交织，相互影响。即便我们逃离了这个系统，也逃不出那个系统。再没有人和我们毫无关系，再没有人可以独善其身！这就是PFP课程上第一次教练圆圈的案例诊断中，五个刚刚认识的陌生人，借由一个问题，所共同“看”到的宝贵洞见。一个小时下来，每个人都受益匪浅。

每个人都需要*一个教练圆圈

教练圆圈的本质就是一种深度同频和互动的群体对话，这样的对话在这个时代尤显珍贵。

相对于从问题直奔解决方案，教练圆圈的对话经历了一个从有形有相，到无形无相，再到有形有相的U型过程。这个U的转向和下潜非常重要，它把原来表象的问题，经过探究之后，转向事物的核心与本质，也就是“真问题”。所谓＂真问题＂，不再是那个问题及表象本身，而是我们与问题的关系，这是一个从问题中＂见自己＂的过程。电影《一代宗师》中的宫二说：习武之人有三个阶段：见自己，见天地，见众生。很多人终其一生也没有完成第一步，而真正看见自己，是领导力和创造力的真正觉醒。

教练圆圈就是这样一面多棱镜，每个人都需要一个教练圆圈，来看到自己。U型理论的精髓所在，激发个人突破及组织变革关键，就是“让系统看见自己＂。

问题永远都会存在，一旦我们对待问题的视角发生了改变，我们就能从问题之中看到截然不同的世界，我想这也正是颠覆式变革下认知升级的必经之路。

后记

站在奥托身边的这一刻，回想这一年U的历程，也正是我自己不断自我革新，认知升级的道路。从接触u.lab慕课以来，一个又一个震撼人心的视频，让我对MIT的自然流现研究所产生了向往；接着掉进《U型理论》这本厚厚的大部头，社会创新实验室，这个有趣的想法吸引着我，让我不由自主的穿梭在U的世界中采撷不辍。

但愿这篇文章，能够成为你认知升级之路上的一块垫脚石。如果你对教练圆圈感兴趣，想找到合适的小组开始练习，或想加入Ｕ的社群，你可以搜索并关注＂天下Ｕ＂的微信公众号，发送“教练圆圈+姓名+所在的城市＂到公众号后台，就会得到相应的帮助。

现在，开始行动起来吧！

原文链接 mp.weixin.qq.com/s?__biz=MzA5ODExMDc1Mw==&mid=2649635260&idx=1&sn=87cc6a9afc7a8a556af1ca520b5fa890&amp

大家对于采用Scrum模式中如何对待文档还是有不少的困惑的。Scrum联盟会员Ashish Sharma最近分享了他的看法，融合我们自己的心得，在此简要探讨：

Ashish认为这个话题的关键字是：必要的、有价值的、及时的（Essential，Valuable, Timely).

必要的：你的文档应该简单明了、刚好足够。开发工程师不太喜欢冗长的文档，因为经常更新滞后而且难以维护且没有意愿去细看和维护。我们推荐尽量使用非格式化的文档，例如远景概要、路线图、概要架构图、讨论草图、wiki网页等等。对于一些特殊行业的合规要求（例如医疗行业），我们也尽量用最多快好省的方式来产出最小集合的必要文档来符合实际需要。总之，高质量的代码和可随时执行的测试集／测试计划是最可信赖的新型文档。

有价值的：不是为了文档而文档。你是否真的那么需要某些文档？文档不是目的，只是手段。我们会针对不同的目的来确定是否有更好的更高效的，甚 至于更有乐趣的手段代替传统文档。Mike Cohn，引用Tom Poppendieck的话, 建议, “When documents are mostly to enable handoffs, they are evil. When they capture a record of a conversation that is best not forgotten, they are valuable.”

及时的：文档最好是用JIT（Just-in-Time）的态度来生成和维护。大部分文档是贯穿整个开发周期的副产品，渐进演变式的生成，用于辅助我们可工作产品的频密交付，这样你对这些文档对你的价值能及时获得反馈，它们也可以是迭代出来的。这样的方式也可以降低必要文档的总量，并避免对形式主义文档的厌恶情绪。

好处

打磨技能、持续精进、连接人脉、获得认可

9 Reasons Why I Decided to Become a CSP

申请要求

• 拥有CSM/CSPO/CSD认证之一，且未过期
• 过去5年内，至少有36个月的时间在组织内成功地应用Scrum
• 在过去3年内积累70个SEU学分。已经获得的课程认证可以提供了一些学分哦。CSM (最多 16 SEUs), CSD (最多 24 SEUs), CSPO (最多 16 SEUs)

申请过程

一次性申请费用（申请时支付，不退还）为$100, 认证费（通过评审之后支付）为$150。

你可以在Scrum Alliance网站上找到自己的dashboard页面，点击”Apply for CSP Certification” (在”Actions”按钮下)。填写你的36个月的敏捷经验，以及所扮演的”Scrum Role”。还要提供个人简介和联系方式。

申请过程中，评审者可能随时向你会询问和澄清一下内容。

如何积累SEU学分

在70个SEU中，在线学习和视频学习不能超过17个，且每个类别也有上限（防止偏科）。

1. A类（至多45个）。参加各种Scrum社区大会，例如Scrum Gathering大会。
2. B类（没有上限，至少14个）。参加Scrum Alliance授权的课程，例如CSM等认证课，或者像上海优普丰这种REP合作伙伴提供的非认证课（如进阶敏捷教练课程），还有就是接受CTC认证教练的Coaching辅导也可以哦。
3. C类（最多15个）。参加非Scrum Alliance机构举办的敏捷相关课程或活动。
4. D类（最多15个）。参与敏捷社区志愿者服务。
5. E类（最多15个）。独立学习，如准备一个Scrum相关的演讲，写文章，看视频，读书等。每个小时算作一个SEU。
6. F类（最多15个）。其他集体学习，如共同培训(co-train)，参与网络课程等。每个小时算作一个SEU。

参见Earn SEUs for your CSP

刷新认证

每两年需要刷新你的认证，继续积累40个SEU并支付$250费用。

参见 Renew your CSP

原文链接：

http://www.jackyshen.com/2016/06/15/how-hard-to-apply-CSP-certification/

尽管并无权威调查，据优普丰敏捷教练团队多年来在培训过程中，以及作为一线敏捷教练提供咨询教练辅导等服务时，发现这个比例与上述调查差不多。大多数企业都是从Scrum开始，逐步引入Kanban和XP极限编程的工程实践。少数企业从精益看板出发，再借鉴Scrum与XP实践。

从2013年起，“敏捷”似乎成为一股大势，无论互联网初创企业，还是通信、银行、保险等传统组织的IT与产品研发，都纷纷投入这场大潮，国企、民企接触敏捷稍晚，但已经迎头赶上，在实践效果方面不输外企。当然，这些组织进行敏捷转型的背景、动机各不相同，对Agile的理解也参差不齐，但谁也不想在互联网时代错过这班转型与创新的高速列车。

就连一些其他的培训体系机构，见到敏捷市场巨大，也纷纷来分一杯羹，甚至偷换概念，造成鱼目混珠的现象。建议大家在选择时，还是从主流的Scrum出发。如果对敏捷不甚了解，不妨先参加一下UPerform优普丰的CSM基础认证课，得到一线导师的经验亲传，真正理解敏捷是一种思维，再去考虑采用哪些实践和工具。后续更不妨邀请资深敏捷教练贴身辅导，快速建立敏捷转型的基础，帮助大家走上轨道。

几年来,在营造一种健康的创意文化并保护这种文化的过程中,我们总结了一些理念。如果把一个复杂的理念提炼成T恤上的标语,就可能会给别人造成误解,并且提炼的过程本身就已经导致理念内涵的流失。一句值得重复的箴言,其实离—句无意义的空话并不遥远。漂亮话并非一定能付诸实践。我一直认为这种所谓提炼的真理是不足为训的。但是我觉得,在这一章节与大家分享一些我最为珍视的理念,或许可以给大家带来一些启发。但要注意:请把每一条理念当作一个起点或一条往深层探寻的通道,而不要直接视作定论。

• 把高明的点子交予平庸的团队，点子就会毁在他们手上。把平庸的点子交予一支卓越的团队,那么团队要么就对点子进行改进,要么就是将点子推翻,提出更好的构想。也就是说,如果你能组建一支优秀的团队,那么他们就能给你好点子。

• 在聘用员工的时候,请给予他们发展的空间,让他们的技能能够有所提升。这些员工未来能够达到的水平,要比当下展示出来的技能更加重要。

• 永远记得:发掘那些比你聪明的人才。即便雇用强者看起来会造成潜在的威胁,也要冒这个险。

• 如果你的企业里有人不敢畅所欲言地提出建议,那么受损失的人是你。不要因为一个点子的 来源不够“正统”就不重视,因为,灵感可以来自任何地方。

· 仅仅敞开心扉接受别人的点子是不够的。集思广益、广开言路,这是一个需要我们主动采取行动的长期积累的过程。作为管理者,你必须学会激发员工们的灵感,还应该时常激励他们开动脑筋为公司出谋划策。

• 在职场环境里,有诸多导致大家不能坦诚相见的障碍。你的任务就是去挖掘并扫除这些障碍。

• 与你意见相左的人肯定有他自己的理由。你需要去理解对方观点背后的道理。

• 如果你的企业中弥漫着一股恐惧感,那么这背后定有原因。我们的任务有三:一是找出原因所在;二是把原因弄清楚;三是把这原因根除。

• 想要驳倒反对意见,最有效的利器就是对自己观点的笃信。

• 通常来说,在抒发可能会引起争议的观点时,大家都会有些顾虑。而智囊团会议、审片会、事后讨论会以及点评日都是鼓励大家勇于直抒己见的方式。这些鼓励自我评估的方式，都是我们为让大家说真话所做的努力。

• 如果大家在走廊里要比在会议室里更容易说真话,那你就有麻烦了。

• 许多管理者都觉得,如果自己没有对消息掌握优先权或是在会议上被搞得猝不及防，就表示自己没有得到管理者应得的尊重。拜托，别这么斤斤计较好吗？

• 想要轻描淡写地低调处理问题,可能会让别人觉得你要么是在回避问题, 不坦诚,要么就是无知或漠不关心。把问题与大家分享不失为一种团结人心的方法,这样做能让员工觉得自己是企业中的一分子。

• 我们对成败所下的第一结论通常都是错误的。只看结果而忽略过程的评估方法是会造成误导的。

• 不要天真地认为只要能规避错误,你就不必费心纠正错误了。实际上,规避错误的代价往往要比纠正错误的代价更惨重。

• 变化和不确定因素皆是人生的组成部分。我们不应抗拒变化，而应该磨炼在意外发生时迅速恢复的能力。如果你不能时刻准备揭露和探索那些不可见的因素，那么你就不能成为一名合格的领导者。

• 管理者的任务并非规避风险,而是营造一个让员工能够安全承担风险的环境。

• 失败不一定是坏事。实际上,失败一点儿都不能算是坏事,而是做新尝试时必然出现的一种结果。

• 信赖他人并不代表你相信此人不会犯错,而是在他犯错时你仍然信赖他。

• 在遇到问题时,负责实施计划的人必须拥有最终决定权,也就是说,他们不必得到上级批准就可以制定相应决策。寻找问题以及解决问题是每个员工的责任,每个员工都应该拥有暂停流水线的权力。

• 事事都顺利进行是不可能的。如果以此为目标,会让你以员工所犯的错误作为评判标准,而忽略了他们解决问题的能力:

• 不要妄想等到事事完美再公之于众。早些与人分享,多多与人分享。作品在完成之时会绽放光彩,但是在制作过程中却只是丑小鸭。

• 一家企业的沟通体制不应成为组织结构的翻版,人与人的交流不应有等级的阻隔。

• 切忌制定过于烦冗的规矩。规矩的确可以为管理者减轻负担,但也会为其余95%的人带来羁绊。不要为了5%的人的利益而设置规矩,对于有违常理的行为单独处理就好。这虽然会加重管理者的工作量,但最终对企业的健康发展是有好处的。

• 有时,设定限制反而能激发创意。令人不适或看似不稳定的环境,或许能催生优秀的作品。

• 挑战那些极端困难的问题,能迫使我们用新的视角看问题。

• 一个组织要比构成组织的个人更容易停滞不前、难以改变。不要以为泛泛的协议就意味着改变。即便大家表面赞同改变,但想要让一支团队真正行动起来,是需要你实实在在付出心血的。

• 在运作良好的企业中,各部门的工作事项虽然存在差异,目标却是彼此相联的。如果只偏重单个部门的工作事项,那么大家的利益都会受损。

• 想要见证伟大,就必然经历一段不伟大的平庸,这个道理有些人是不能理解的。在创意环境中,管理者的任务就是捍卫新生的构思不受这些人的推残。放眼未来,不要驻足过去。

新出现的危机并不一定意味着噩运, 这些危机可以测验和彰显一家企业的价值所在。另外,解决问题的过程往往可以将员工们的心凝聚在一起,敦促大家将目光放在当下。

• 卓越、品质和优秀这三个词应该是通过付出而获得的,应 由别人冠给我们,而不是由自己来宣称。

• 不要一不小心把稳定错当成了目标。平衡要比稳定来得重要。

• 不要将目标与方法混淆。我们应坚持不懈、不遗余力地通过优化、简化及提高效率等方式努力改进我们的工作方式,但这并非我们的目标。打造出优秀的产品才是我们的目标。

用户故事是敏捷开发中流行的需求表达手段，各种敏捷流派中都提倡将大型需求进行化整为零，减少颗粒度，提高灵活性，实现尽早交付价值和揭示风险。本文根据 @申导 多年敏捷实践经验，同时借鉴业内流行做法，整理出一套分解用户故事的模式，分享给大家。并且最后也给出了优秀的用户故事需要满足的3C特征及INVEST原则。

各种分解的招式

1 Functional Requirements 功能性需求

1.1. Take a thin slice through the workflow; or do beginning and end of the workflow first and then the middle of the flow. 先从工作流中剥离出薄薄的一层进行开发；或者先完成工作流的头尾部分，然后再完成中间步骤。

As an Amazon user, I can buy a book online so that I can buy book everywhere.

• As a Amazon user, I can search for a book so that I can buy it
• As a Amazon user, I can pick book into shopping cart so that I can pay for it later
• As a Amazon user, I can review my shopping cart so that I can change my mind
• As a Amazon user, I can check out shopping cart so that I can ask for delivery
• As a Amazon user, I can pay with PayPal so that I can easily transfer my money to Amazon

1.2. Split multiple operations in the story into separate stories. (e.g. story about managing or configuring or CRUD) 按照多个操作分离成不同的用户故事（例如，关于”管理”、”配置”或”CRUD”的故事）

As a iPhone user, I can manage my contacts so that I can keep in touch with my friends.

• As a iPhone user, I can browse my contacts so that I can see who are in my contacts
• As a iPhone user, I can delete a contact so that I can shorten the list
• As a iPhone user, I can create a contact so that I can remember my friend’s phone number
• As a iPhone user, I can edit my contacts so that I can remember my friend’s new phone number
• As a iPhone user, I can share my contacts so that others can get this information easily

1.3. Do a subset of the business rules first and enhance with additional rules later. (e.g. a domain term in the story like flexible dates that suggest several variations?) 先完成业务规则的一部分，然后再进一步增添其他规则（例如，包含的领域术语”弹性日期”的故事暗示着多种变化）

As a Aeroplane Chess player, I can move my spawn in order to play

• As a Aeroplane Chess player, I can only start moving my spawn when roll a 6
• As a Aeroplane Chess player, I can move my spawn according to the roll
• As a Aeroplane Chess player, I can move my spawn thru shortcut when it stop at the teleporter
• As a Aeroplane Chess player, I should move my spawn backward when meet the end point

As a JIRA admin, I can see permission of all users

• As a JIRA admin, I can see permission of individual so that I can join him to a project
• As a JIRA admin, I can see permission of project member so that I can ensure proper authorization for projects
• As a JIRA admin, I can see visitor permission so that I can release temporary access in time

1.4. Process one kind of data first and then the other variations later with same operations. 先处理一类数据，然后再处理基于相同操作的其他类型的数据。

As a online banking user, I want to transfer my money so that I can make transactions everywhere

• As a online bank user, I can transfer money to my own accounts
• As a online bank user, I can transfer money to other bank account
• As a online bank user, I can make international transfer
• As a online bank user, I can pay bills

1.5. Handle data from one I/O channel first and enhance with the others that handle the same kind of data later. 先处理来自某一个渠道的数据，然后再关注处理同类数据的其他渠道。

As a citizen, I can view PM2.5 rating from all the data publishers so that I can get an average assessment.

• As a citizen, I can view PM2.5 rating from U.S. Embassy.
• As a citizen, I can view PM2.5 rating from National Meteorological Centre.

1.6. Split for different roles. 按照不同的角色来分解。

As a WebEx user, I can schedule a meeting so that I can connect to my colleagues

• As a mobile WebEx user, I can schedule a meeting with iPhone so that I can take a walk during the meeting
• As a desktop WebEx user, I can schedule a meeting with desktop browser so that I can get full features of a meeting
• As a user, I can login to the online store

• As consumer user, I can login to go shopping.
• As admin user, I can login to manage the big data.

1.7. Strip low priority from high priority. 将低优先级与高优先级需求分离。

As a user, I’m required to log into the system so that I can access the system.

• As a user, I can login into system with correct username and password so that I can access the system
• As a user, I want to be frozen access for logging in with invalid password three times.
• As a frozen user, I want to be sent an email notifying a malicious attempt was made.

2 Non-Functional Requirements 非功能性需求

2.1. Make it work first and cross-cutting concerns to reduce the complexity. Such as Performance, Conceptual Integrity, Reusability, Availability, Interoperability, Manageability, Scalability, Security, Supportability, Testability, Usability, Maintainability, Auditability and Reliability. 使软件先工作起来，推迟跨领域的关注点，包括性能、概念完整性、可重用性、可用性、互操作性、可管理性、可伸缩性、安全性、可支持性、可测性、易用性、可维护性、可审计性、可靠性。

[Performance] As a new user, I want to be able to login to the system and join the meeting quickly when I use it first time so that others don’t need to wait for me.

• As a new user, I want to be able to login to the system and join the meeting.
• As a new user, I should complete application downloading within 20 seconds.

[Manageability] As a privileged user, I can see restricted search results so that I can make sure information confidential

• As a privileged user, I can see all search results.
• As a privileged user, I can see restricted search results that authorized to me

[Security] As an online bank user, I want to add payee so that I can pay to it.

• As an online bank user, I want to get current payee list
• As an online bank user, I want to add a payee
• As an online bank user, I want to conduct RSA token authentication before adding a payee

[Security] As an attacker, I must not be able to inject SQL with malicious statement.

[Availability] As an operator, I want the system switch over automatically when alarm 1234 raised so that I can continue my business.

[Interoperability] As a user, I want to log in to system with my account.

• As a user, I can sign up to acquire an application account.
• As a user, I can login with my application account.
• As a user, I want to use OpenID as my user identity to login to system, so that I can use my existing accounts of OpenID service provider and don’t need register a new proprietary user account.

[Usability] As a user, I want to start a Webex meeting.

• As a user, I want to start a Webex meeting.
• As a user, I want to start a Webex meeting via a one-click-start tool.

3 Technical Constraints 技术约束

3.1. Evolve architecture design. 进化架构设计

As a client, I can read data from data source.

• As a client, I can connect to JSON file to read data.
• As a client, I can connect to Mysql database to read data.

3.2. Bypass the real external systems first with dummy / fake / stub / mock. 利用仿制品/打桩等先绕过真实的外部系统

As a client, I want to integrated with PayPal interface so that to pay the bill

• As a client, I can pay via a fake PayPal interface that returns “successful”
• As a client, I can pay via a fake PayPal interface that returns “insufficient balance”
• As a client, I can pay via real PayPal interface

4 Spike 尖刺

4.1. Separate simple/complex, do the core first that provides most of the value and/or learning and enhance it with later stories. 区分简单与复杂，先完成提供最多价值或知识的核心部分，以及解决最严重的阻碍，澄清需求和约束，然后再进一步完善。

As a user, I can search for game cards and see result grid in same screen.

• As a user, I can search cards with title and text and see total amount found so that I know searching is done
• As a user, I can see result grid so that I can see detailed result
• As a user, I can search with criteria including sets, types, houses, abilities so that I can make advanced searching

4.2. Setting up infrastructure component can be verified alone. 搭建基础设施组件的工作可以被独立验证。

I want to setup Weblogic environment in order to deploy backend services on that.

4.3. Can you do some trace bullet such as mockup / experiment / simulation / prototype to evaluate the new tool / framework / language/ algorithm within a time-box within a time-box to see what can be achieved? 你是否可以在时间盒内做些端到端的概念验证，比如模型/实验/模拟/原型等，来评估一下新工具、框架、语言、算法，并看看所取得的效果？

I want to do a POC with Robot Framework for automation test in 10 days, in order to see whether it suitable for current project and developers’ skills

I want to compare the pros and cons between Maven and Ant in 5 days, so that we can decide which to use in the coming project.

As a client, I want to connect to “component X” which is ported from legacy system to new system in order to keep the interface unchanged

Collect all messages from/to “component X” monitored on legacy system to understand the behavior first
Next step…

Evaluate the split 评估分解的成果

• Do each of the stories satisfies INVEST? 每个用户故事都符合INVEST吗？
• Are the new stories roughly equal in size? 新的故大小是否基本一致？
• Is each story about 1/10 to 1/6 of your velocity? 每个故事大小都在你的速率的1/10到1/6之间吗？
• Are there stories you can deprioritize or delete? 这些故事可以被丢弃吗？
• Is there an obvious story to start with that gets you early value, learning, risk mitigation, etc.? 哪个故事明显可以先开始，从而带给你早期价值、学习、缓解风险吗？

Reference: Good user stories satisfy INVEST 参考: 好的用户故事满足INVEST

• Independent: The user story should be self-contained, in a way that there is no inherent dependency on another user story. 独立的：用户故事应该是独立的，没有对于其他用户故事的内在依赖。
• Negotiable: User stories, up until they are part of iteration, can always be changed and rewritten. 可协商的：用户故事在进入迭代之前，都可以进行变更和重写。
• Valuable: A user story must deliver value to the end user. 有价值的：用户故事必须向最终用户交付价值。
Estimable: You must always be able to estimate the size of a user story. 可估算的：用户故事的大小必须总是可以估算的。
• Small: User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. 尺寸小：用户故事不应该过大，以至于无法在一定的确定性下进行计划、分派和排列优先级。
• Testable: The user story or its related description must provide the necessary information to make test development possible. 可测试的：用户故事及其相关的描述必须提供必要信息，允许对开发进行测试。

Reference: 3C of User Story 参考: 用户故事的3C特征

• Card: stories are traditionally written on note cards, and these cards can be annotated with extra details. 卡片：习惯上将故事写在便条卡片上，这些卡片可以标注额外的细节。
• Conversation: details behind the story come out through conversations with the Product Owner. 交谈：与产品负责人的交谈中产生故事背后的细节。
• Confirmation: acceptance tests confirm the story is finished and working as intended. 确认：使用验收测试来确认故事的完成和符合工作要求。

“Spotify的新型敏捷矩阵组织：部落、分队、分会和协会”出了以后，很多人对Spotify的敏捷组织形式非常感兴趣。这里@申导 抢鲜给大家带来第二部分，关于Spotify的敏捷工程文化。

第一部分主要提到基于敏捷原则，将人按照小分队Squad的方式来组织，松耦合但紧密联盟(Align)。通过内部代码开源，鼓励“异花传粉”。通过架构解耦、特性开关等手段来做到频密的小规模发布。借助自助的发布和部署服务，减少人们之间的任务交接。所有一切都关于“人”，因此组织更加要关注激励、信任与社区文化，而非等级结构或控制。

第二部分讲的是关于失败，用Spotify的创始人Daniel的话说就是，“我们要比其它人更快地犯错误”。因为失败意味着学习，因此更快地失败就意味着更快地学习，更快地改进。

把人关在笼子里是比较安全，但很难学习到东西，人也不会觉得快乐。而探索世界虽然可能受更多的伤害，但更加快乐，更快地成长，至于伤口，总会愈合的。在一个“对失败友好的环境”中，鼓励大家面对失败，庆祝失败，而不仅仅是避免失败。

失败不单纯是失败，而是是为了学习。在几周一次的回顾会议中，不要过多关注“谁犯的错？”，而是更多关注“我们学到了什么？”和“我们将要做出哪些改变？”，从而避免将来犯同样的错误，针对产品也针对过程。这样才能做到持续改进，改进需要自底向上的驱动，也需要自顶向下的支持。

失败也是有代价的，得想办法控制成本。比如通过架构解耦，将缺陷控制在有限范围内，不影响其他组件，快速修复出问题的那一部分。再比如利用“灰度发布”，一开始只将新功能推给有限的用户，确认稳定后，再快速分发给大众用户。这样，即使新功能出了问题，影响的人群和时间也都是有限的，也就更有底气去做试验、学习。相反，“如果一起尽在掌控，你就落后了”。

关于产品开发，Spotify借鉴了精益创业的思想。产品开发最大的风险来自于构建了错误的产品。因此，在实现一个新点子之前，可以先针对有限人群做访谈、试用原型，看看新功能对人们的影响(Impact)是什么，人们的行为会有什么样变化。下一步才是构建MVP(最小可行产品)，然后通过例如A/B发布的形式分析用户行为数据，再对产品优化调整。

管理者经常会问，“我们什么时候发布？”然而，100%的可预测性会扼杀创新，关注对用户的影响比关注团队产能意义更大。固定的交付时间显然在某些情况下有意义，特别是配合市场推广或者第三方集成的时候，但是要尽可能推迟决策。减小了遵循计划的压力，就更加可能关注交付价值，让人们更加投入于工作。

在Spotify，鼓励人们有10%的Hack Time来尝试一些新的想法，甚至利用整周的Hack Week来真正地做出些够酷的东西来。人们天生就是创造者，那就给他们一些时间来创造吧。

在“对失败友好的环境”中，很多事情没有固定的正确答案。与其无休止的争论，不如看一看“现在的假设是什么?”、“我们学到了什么？”、“接下来要尝试什么？”，让现实数据来驱动决策。

在一个消除浪费的精益文化中，人们会保留有用的实践和工具，同时快速地停止做那些无用的事情。

大型项目意味着更大的风险，尽量将工作分解为更小的组成部分。一定要做大型项目的话，那就可视化整个项目、每日同步、每周演示，尽早地进行集成，尽早反馈，尽早暴露风险。同时，让产品负责人与技术负责人组成领导力小组，从整体上进行把握。

随着团队的成长，烦恼也随之而来。团队随时会陷入混乱，但过多的约束也会让组织滋生官僚。作为管理者要在混乱与官僚两者之间寻求平衡，找到“最小可行的官僚”。

消除浪费的艺术，在于可视化并且经常进行讨论。因而团队除了回顾会议，还建立了改进看板(Improvement Board)，展示当前的障碍和后续行动。就某项改进，借助Toyota Improvment Kata，可以分别对现状、长期目标、短期目标，行动项队列进行分析，利用不断的短期胜利逐步接近最高标准(Definition of Awesome)。

健康的文化可以修复破损的过程。文化如此重要，以至于没有人会“拥有文化”。可以建立专注于文化的角色例如教练协会、Boot Camp新兵训练营、分享经验的故事会（@申导 曾经工作过的NSN也早就建立过这些实践了），来保持文化的健康。

文化不是一句口号，而是每个人的态度和行为汇集在一起的表现。每个人都是文化的一部分，每个人都要以身作则地践行所期望的文化。

更多参考：

https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/
LeSS
SAFe
http://www.scrum-breakfast.com/2013/10/scaling-scrum-safe-dad-or-less.html

关于需求的讨论

最近在辅导敏捷团队和教授Scrum课程中，发现团队提出的很多的问题现象可以归结为迭代前讨论不充分所导致。
根据自己多年亲身实践的敏捷经验，如果在迭代的计划会议上，团队并没有澄清和理解需求，而是在迭代过程中再进行需求澄清，那么往往导致“迭代紧张、测试不充分、估算不准确、精神面貌不良”等表面现象。
因此，对需求的充分理解应该是迭代的入口条件，应该成为Defenition of Ready的一部分，来确保迭代能够健康地开始。
然后，更深入的根源则是团队不了解如何进行一场充分的讨论。

敏捷是一种辅助实现交付价值的手段，不应该过于繁重。下面就根据@申导 早年在诺基亚西门子通信工作时所学到的一种简易讨论法：Scope-Question-Assumption（简称SQA）讨论会。

角色

Product Owner 或业务方
负责讲解需求，回答关于需求细节与优先级的问题。
Scrum Master 或引导者或主持人
负责设计讨论议程，计时、控制场面。

团队

负责提问、评估技术风险、对需求给出建议、澄清细节、给PO提供方案选择、将需求分解为验收条件。

过程

找一间开阔的会议室或者讨论区，移除多余的桌椅，便于走动。
在墙上事先贴好多张白板纸（大白纸、Flip Chart）。在大白纸上分别写上Scope范围、Question疑问、Assumption假设。
团队分为3-4人的小组，包含开发与测试。主持人不参与讨论，负责计时和引导过程。讲解需求的人作为自由人在各小组轮流走动。
由PO迅速讲解各个大需求。然后每组“抢”一些需求卡片，按照对需求的清晰度来分类为“大便、石头、钻石”。
按顺序针对一个用户故事或需求点进行讨论。在Scope范围纸上记录下要做或者不要做的需求内容，以及分解以后的验收条件。在Assumption假设纸上记录下目前方案基于的假设与依赖，这些可以是当前确定的共识，但将来有可能存在变化的风险。在Question疑问纸上记录下目前PO无法回答的疑问，在会后需要进一步澄清。
每15分钟，每个小组留下最熟悉和最不熟悉的各一个人，其余人按照顺时针移动到下一个小组去提问。每组留下的人负责给其他组移动过来的人讲解目前的讨论结果，解答问题，一起继续讨论。在这个“异花传粉”的过程中，不同人的不同想法会得到碰撞、激发、涌现，形成“杂交优势”，所有人能够“共同进化”。
（可选）随后可以根据情况，决定是否进行任务分拆。除了最熟悉和最不熟悉的人，其他人自行决定加入哪组。花20分钟自行分解任务。分解后的粒度希望达到2天左右工作量的大小，并且能够开发、测试及演示，或称满足DoR。
主持人询问大家对结果是否满意，以及为什么不满意。
任务拆分的结果同样可以用“大便、石头、钻石”来分类。并采用动物体积、T-Shirt Size、相对故事点等方式进行估算。

大便、石头、钻石

大便：不知道在说什么
石头：需求清楚，但有些测试场景还没想全
钻石：需求100%清楚

产出

验收条件，具备实例，最好能够转化为自动化测试。可以借助Given-When-Then的格式来编写。
其他辅助澄清需求的格式，包括流程图、顺序图等图表。
分解后的用户故事。
优先级重排之后的产品待办项列表。
相对估算结果

参考：
需求梳理工作坊引导技术

最近的课程碰到了很多ScrumMaster和Product Owner对于打造高效能团队（效率和效果并重）的困惑和疑问，这也促发我们对这个问题再次的关注、思考及总结。简而言之，我们觉得团队的打造方向就是四个重点特征：纪律性；主动性；合作性；创新性。

纪律性：
纪律性是敏捷研发和交付团队的基础，千万不要因为我们敏捷起来以及团队自组织，就不需要纪律。敏捷团队的纪律性可以说比任何其他研发模式的团队更为甚之。敏捷团队的纪律性无处不在，例如：频密的检视和作出必要的调整，不论是产品本身还是微观工作方式和过程；频繁交付可用产品；严谨的DoD条款；对时间盒的尊重；对团队合作规则的尊重和遵守；节奏；信息可视化；频密提交、持续集成和自动化测试，等等。

主动性：
没有主动性，何来竞争力？对比其他的模式，包括其他敏捷方法，Scrum是特别强调团队主动性的工作方式。我们期望通过多种举措和引导技能带来和培养团队主动性。例如，PO想办法让我们做的产品更有意义和意思，懂得从为什么开始来进行思考和沟通；重视Sprint的目标，特别是业务目标；有一个优秀的ScrumMaster或者敏捷教练来打造团队；鼓励团队在对目标形成共识的前提下，开放地发表想法并热烈讨论，并尽早付之行动和检视成果；鼓励团队追求成长和提升，追求匠艺，并分享；真正落实自组织，不去干预和不去微观管控开始，等等。

合作性：
三个臭皮匠顶一个诸葛亮！但他们需要合作，才能有成效。就算我们大家都是高手，也需要合作。Smart, but willing to work as a team player!（来自谷歌的招聘原则），不然还不如单干罢了，简单多了，还不会内耗。合作性首先来源于对最终成果的共同负责，这太重要了。放下原来的Titles和成见，一起探讨一下我们的共同目标是什么，同时拥抱和尊重多样性，对大家怎样在一个团队里工作制定一些规则，并持续去改进和调整。利用好回顾会议也是一个关键。其他支持合作性的实践还有：跨职能团队和个体；结对编程；内部或外部社区分享（异花传粉）；共有代码权；在一个房间里工作；团队估算，等等

创新性：
纪律性和主动性带来效率，但合作性和创新性带来价值创造的效果。创新性不容易。我们的教育没有培养过这种心态和能力。我们在努力工作的同时，也要有空间来尝试工作得更聪明。我们总是在有限的人力物力和时间内工作，我们应想尽办法创造出最大的价值，有时候是微创新，有时候是奇思妙想。团队既要关注创造性地解决用户和客户的问题，也要留意创造性的提升我们的工作方法。支持创新性的实践包括：Design Thinking（设计思考）；Impact Mapping；可视化；到客户现场；创造性的排优先级和Kano模型；砍需求；减少冗余的各种岗位品种；流程价值流Mapping；反思反思再反思；拥抱“石头的寓言”；异花传粉；精益创业思想和实践，等等

单元测试(unit testing)已经越来越得到广大开发者的认可。作为低成本、速度快、稳定度高的自动化测试手段，单元测试可以在类和函数级别对代码进行质量守护，有助于避免尴尬、耗时的错误。当然，相比功能测试(Functional testing)和端到端测试(end-to-end testing)，单元测试能够寄予的产品级别的信心要略低一些，因而各个粒度的测试应该是相辅相成的，互为补充。

常常听到一些组织要求开发团队提高单元测试覆盖率，换来的却是怨声载道，或者是一堆应付差事的垃圾测试（没有断言的测试，都见过吧）。尽管，低测试覆盖率意味着对质量的信心不足，但是，单元测试覆盖率真的要达到100%才好吗？

100%听起来肯定比95%要好，但是区别在于那些额外测试的价值对你可能是微不足道的。这要看哪种代码没有被测试覆盖，以及你的测试能否暴露程序的错误。100%的覆盖率并不能够确保没有缺陷——它只能保证你所有的代码都执行了，而不管程序的行为是否满足要求。与其追求代码覆盖率，不如将重点关注在确保写出有意义的测试。

测试越多，额外测试的价值越少。第一个测试最有可能是针对代码最重要的区域，因此带来高价值与高风险。当我们为几乎所有事情编写测试后，那些仍然没有测试覆盖的地方很可能是最不重要和最不可能破坏的。

编写一些测试是不费脑筋的，但随着我们接近完全的代码覆盖率，我们不那么确定了——我们差不多已经为一切都编写了测试，而剩下的没有测试的代码是微不足道，几乎不会破坏。这就是所谓的收益递减。要想从单元测试中获得更多的收益，需要重新将单元测试从质量工具定位成设计工具。TDD等方式可以帮助我们做到这一点，（关于此话题，敬请期待@申导 翻译的《Effective Unit Testing》一书。）

换句话说，向代码基增加100个精挑细选的自动化测试是明显的改善，但当我们已有30000个测试时，这些额外的100个测试就无足轻重了。

比赛场上的赢家是那些将注意力集中在赛场上的选手，而不是紧盯着计分板的人。—巴菲特

总之，当你觉得生产环境中报来的bug很少了，或者你能够自信地对代码随时进行修改，单元测试就已经足够多了。

另一方面，也有些观点认为，不但不值得追求高覆盖率，甚至写单元测试本身就是非常耗时和难以维护的重复工作。这种极端观点我同样不赞同。

代码覆盖率不能告诉我们代码质量的高低，也不能用了评判开发人员的绩效。但它能够告诉我们哪些代码还没有被测试覆盖，哪里有漏网之鱼。至于这鱼值不值得抓，还是取决于开发人员的经验进行风险判断。那么，接下来我们再来分析一下，到底哪些鱼值得抓。

图中，产品代码可以分为四个类别，纵轴是从单元测试中得到的收益，横轴是单元测试的成本，我们从投入产出的角度来分析，到底哪些代码适合于进行单元测试：

琐碎且无甚依赖的代码。比如getter/setter, 比如简单地调用系统时间，比如 toString()等等，基本是不需要测试的。虽然测起来容易，但我们有信心说它们出错的概率也非常低，测这种代码的确索然无味。
承上启下的代码。比如用MVC框架实现的代码里，某些service层只是简单地被Action层调用，然后转发到下一层去。这种粘合代码不具备太多被测试的价值，而且由于是衔接上下两层的传话筒，测起来却需要对周围各层进行mock或打桩。要想验证其所做的那一点点工作，其实还挺麻烦的。当然，也有一些观点比如”London School TDD”坚持认为，对于企业级应用，就要像制作香肠一样，一层一层地对交互(interaction-based)进行测试，每测一层都需要mock的帮助。
具有算法和业务逻辑的代码。比如排序或处理数据等代码，这些是最值得进行单元测试的代码了。虽然有一定的成本，但是由于算法逻辑的输入输出非常确定，结构复杂且具有业务价值，外部依赖较少，在这上面投入是一定可以得到丰厚回报的。这即是”Classic TDD”观点，对状态进行测试(state-based)。
过于复杂的代码。充满复杂逻辑、交织在一起、散发着各种坏味道的遗留代码，就像一座未开发的金矿，你需要做很多清理工作，才能顺利地进行开采，否则将寸步难行，不知从何下手，而且成本极高。这种代码建议先进行粗粒度重构和接口测试（孰先孰后要根据实际情况），破除掉严重的依赖，找到所谓的接缝(Seam)，将具有逻辑的部分与承上启下的代码分离开，然后立即将单元测试注入到接缝中，形成对有逻辑代码的保护网，随后继续缩小重构的范围，不断地添加测试和重构，逐渐渗透形成一张网，将又臭又硬的代码块切碎。
除了3）以外的代码怎么测？可以采用其他测试手段，比如功能性测试来进行粗粒度覆盖，同样能提升对产品的信心，并且成本更低，特别适合敏捷迭代式开发，能够在有限的时间盒内达到预期的质量水平。

此外，持续地重构代码，同时编写更有效的单元测试，也是敏捷开发者应该具备的基本功，有助于提高投入产出比。

参考：

http://martinfowler.com/bliki/TestCoverage.html

http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/