团队

当旧有的问题解决方式和决策方式不再奏效，甚至会陷入“越解越乱，越扑腾死得越快”的尴尬境地时，我们该如何去调动深层智慧，不被问题表象所惑，跳出现有认知模式的束缚，去看到全新的解题思路呢？今天，就让我们从这个U型的核心流程＂教练圆圈＂说起，来个管中窥豹，看看这个在＂政商社学＂各界领导者中产生广泛影响的U型理论，在乌卡时代会带给我们什么样新的启示？

如何分拆硬件研发中的产品增量? 这个例子来自德国纽伦堡的某个硬件产品团队，他们在5年前开始导入LeSS（大规模敏捷）。

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

用户故事是敏捷开发中流行的需求表达手段，各种敏捷流派中都提倡将大型需求进行化整为零，减少颗粒度，提高灵活性，实现尽早交付价值和揭示风险。

最近在辅导敏捷团队和教授Scrum课程中，发现团队提出的很多的问题现象可以归结为迭代前讨论不充分所导致。 根据自己多年亲身实践的敏捷经验，如果在迭代的计划会议上，团队并没有澄清和理解需求，而是在迭代过程中再进行需求澄清，那么往往导致“迭代紧张、测试不充分、估算不准确、精神面貌不良”等表面现象。