极限会议: 原则与实践

luobosi.rules_

极限会议是解决开会过多, 会议效率低下的一组原则和实践. 它基于两个简单的理念:

  • 如果一个实践是有用的, 那么我们能不能把它做到极限?
  • 如果每个人都尽自己极限努力推进会议进程, 那么会议定会卓有成效.

会议效率是产出和所花时间的比值. 我们的原则跟实践, 有的致力于提升高价值产出, 有的致力于缩短所需时间, 有的两者皆涉及.

比如说:

  • 如果答疑对听众是有价值的, 那么我们能不能把它推到极致? 极致就是如果没有人有疑问, 就不要召集会议, 由有问题的人召集会议, 而不是有信息的人召集会议, 把推模式变成拉模式.
  • 如果做结论是好的, 那么我们能不能从第一分钟起就开始做结论?
  • 如果换位思考是好的, 那么我们能不能把它做到极致, 与会人员交换立场来发言?

这类实践会比较多, 本文主要介绍在其它类似主题的资料中少有涉及的几种实践. 更全面的实践敬请期待后续介绍.

会前实践

实践: 缺省是不参会

最节省时间的方式是减少参会的数量. 对于所有会议, 缺省是拒绝参加, 除非满足以下两点之一:

  • 你有问题想当众获得答案
  • 别人有问题想当众获得答案, 而你有其他人没有的信息或观点

总结一下就是, 如果你可以不发言, 就可以不去开会. 不发言意味着你对会议议程和结果不会产生影响, 同时你有很多其它途径可以获得会议内容及结论. 而一个等价的关于会前准备的规则是, 要么带着问题参会, 要么带着信息和观点参会.

如果你不确定自己有没有问题, 比如会不会讨论中触发你的疑问, 那你随便, 自己决定.

开场实践

如果做结论是好的, 我们从第一分钟起就做结论.
实践: 一分钟结束会议常识是会议结束时要有结论. 而常识往往不是最高效的. 有多少次, 你听着主持人开场介绍各种背景, blablabla, 而你不知道重点该听哪一句, 思考哪个方面. 好一点的主持人会介绍会议目的, 但依然无助于快速得到结论.既然你已经不得不来开会了, 那么节省时间的手段无非就是如何尽快的得到结论从而结束会议. 能花一分钟就不要花两分钟. 一种做法是先说结论, 先表决结论, 不一致了再讨论, 一致了就可以随时散会了. 这个实践也叫: 先表决再讨论.

最常见的两个例子, 是面试和工作量估算. 几轮面试完毕, 面试官开碰头会决定候选人去留的时候, 可以先手势表决, 如果大家意见一致了, 那么后面的讨论就可以随意点了, 你如果有事中途离席也影响不大了. 不一致了再讨论.

工作量估算也一样. 如果你还保留着估点的陋习的话, 那么一开始也是先表决, 意见一致或接近, 讨论时间就可以压缩.

每条规则都有适用场景. 你可能觉得一分钟结束会议适用于封闭性结论的讨论, 比如上面的去留或点数. 对于开放式的讨论, 开场根本就没有结论, 如何表决?

上面的质疑是有道理的. 但即使对于开放式的讨论, 也可以开场就扔个结论出来, 不过其意图不是快速结束讨论, 而是更好的激发讨论.

会中规则

如果积极思考是好的, 我们就把它做到极限.
下面的抛玉引砖, 欺负老实人, 挤牙膏等实践希望把与会人员的思路激发到极限.
实践: 抛玉引砖你很不幸, 会议没有在一分钟内结束, 只能让讨论尽可能高效了. 人们总是善于批评, 拙于创造. 利用这一点, 你只需扔块玉, 就能激起民愤, 群起而攻之, 一堆板砖飞过来.为什么不叫抛砖引玉呢? 这牵扯到对初始结论的要求. 初始结论必须极端, 才易于激发讨论. 它要么是工作量最小最简单的, 要么是最大最复杂的, 要么是最无厘头的. 总而言之, 你需要脑洞大开. 四平八稳的结论无助于大家思考.

比如对于任何(注意是任何)需求实现方案的讨论, 你都可以这样开头: “这个功能, 我们打算用导入导出Excel来实现, 大家有什么意见吗? “ (“有, 为什么不用金数据?” “…”)

实践: 欺负老实人

有时候作为主持人, 你感觉到场内不是每个人都精力集中, 开动脑筋, 而是开小差, 看手机等. 或者即使不看手机, 也感觉没有投入. 如何让大家始终精力集中呢? 你只需缺省做出对大家不利的结论即可, 除非参会人员抗争, 否则就是定论.

还是拿估点的陋习举例, 尤其是你的交付方式是基于承诺的风格的话. 在计划会议上, 你可以宣布, 所有story, 缺省都是一个点, 或者都必须在一天内完成, 除非开发团队拿出足够的理由. 这时大家为了合理的工作计划, 必须全神贯注的讨论对Story的理解.

会有一些副作用吧. 所有规则都有适用场景. 这个适用于跟团队的信任关系已经建立起来, 团队理解这是讨论的技巧而不是真正的压迫.

实践: 挤牙膏

有时你会发现气氛比较沉闷, 掌握最多信息的人拼命在说, 想把知道的一切都告诉大家, 但听众没什么反应. 一个可能的原因是你说的太多了, 剥夺了听众主动思考的机会. 那么指导思想很简单: 说得越多越沉闷, 问得越多越活跃, 我们只需要制造一种张力, 让团队不得不问.

还是拿估点陋习来说. BA惜字如金, 拿着Story, 除了念一遍, 不做任何解释, 就让大家估. 除非开发人员发问, BA不需要说任何一个字. 就算是回答开发人员的问题, 也点到为止, 一个字都不多说, 除非开发人员继续发问. 反正缺省都是一天做完, 而BA可以通过Story Kickoff, Story Signoff等手段来把关不会有验收条件缺失. 开发人员要争取合理的开发时间, 必须主动发问以获得足够的信息. 这在基于承诺的开发方式中比较适用.

如果获得全面的观点是好的, 我们就把它做到极限.

下面留白, 拱卒, 暗牌, 叛变等实践, 都是为了获得最全面的意见.

实践: 留白

如果你有多于其他参会人员的上下文, 甚至你知道讨论的话题某种程度上在开会之前就已经有结论了, 但你又想知道大家真实的想法, 各自的逻辑, 以便更好的利用集体智慧, 那么你应该留白, 不要一次性把所有上下文和结论都扔出去, 而是随着讨论的推进, 一点点的把约束加上.

上周项目开工会之前, 韵涛纠集了少数几个人上午讨论了下开工的准备工作, 有了一个初步的事项列表. 下午整个项目组开工讨论的时候, 我并没有直接抛出上午的结论, 而是让大家提供自己的意见, 就当上午的会没有发生过. 上午的结论只是备胎, 查缺补漏.

实践: 拱卒

有时你提供了发言机会, 但发现机会被少数人把持, 其他人参与程度不高. 常见的建议是轮流发言. 这里我要说的是, 仅仅轮流发言是不够的, 顺序很重要.

参与程度不高的两个原因是:

  • 即使我不参与, 反正也有别人参与, 即使没有我的输入, 反正也能得出结论.
  • 别人都已经说了, 我没有什么新东西.

那么我们可以让寡言者, 对话题不熟悉不权威的人先发言, 上面两条原因的前提都不存在了: 此时还没有别人参与, 别人也没说什么, 那么我不得不说. 而对话题上下文比较熟悉的人, 永远都可以在后面补充, 他们不会有什么顾忌.

统计表明, 机长驾驶飞机的事故概率高于副机长驾驶飞机的事故概率, 因为机长驾驶的时候, 就算副机长发现有什么不对劲, 也不太敢指出. 而副机长驾驶, 机长在旁边监督, 一旦发现什么问题, 机长是没什么顾虑的. (信息来自<<异类>>). 这是类似的做法.

实践: 暗牌

跟拱卒类似, 你想获得更全面的观点, 但又担心部分人员被权威影响. 那么只需让每个人准备好自己的观点, 同时亮出来就可以了. 这样异议就会暴露出来, 获得足够的关注. 面试和估点依然是常见的两个例子. 它跟一分钟结束会议形式类似, 意图不同. 一分钟结束会议是为了节省时间, 暗牌是为了暴露异议.

实践: 叛变

当你总是基于自己立场的话, 你是狭隘的. 常说要换位思考, 那为什么不直接换位呢? 销售和产品团队开会, 销售人员从产品团队立场去辩论, 产品团队从销售立场去辩论. 任何涉及多种角色合作的会议, 都可以尝试换位.

如果具体比抽象好, 那么我们就举例说明, 看图说话

实践: 比如说

有的人说话形容词副词太多了, 动词名词代词量词数词太少. 智能的, 自动的, 高效的, 等等. 碰到这种情况一定要摁住, 让他举例子. 你不需要在意他说了什么东西, 你只需要在他说完一句话停顿的空隙朱唇轻启补上一句: “比如说?

实践: 看图说话

这个在别处有详细介绍, 比如<<视觉会议>>等. 不多说了.

如果简短是好的, 我们就做到极限, 一个词, 一句话, 一分钟.

实践: 调教

有的人讨论很发散, 表达很跳跃, 永远都是在陈述, 在打转转而不对原始命题表态. 这种情况一定要摁住, 让他做完形填空. 打断他直接追问同意还是不同意, 限制他一个词或一句话或一分钟表明立场.

一个完形填空的例子就是Elevator Pitch, 提供一种结构化的断言, 来收敛结论.

收官实践

如果达成共识是好的, 那我们就追求内心深处的共识.
实践: 闭卷考试“大家都清楚了吗?” 这种问题是没有意义的. 大家都说”清楚了”你也无从确认是否真的清楚了. 而在讨论结束的时候, 我们需要每个人都对当天的结论, 后续的行动有一个一致的认识. 会议结束前我们必须验证大家的理解. 方法也很简单:关掉投影, 擦掉白板, 合上电脑(除了放投影的机器, 这个东西本就不应出现在会议室)和记事本, 参会人员依次回答每个议题的结论, 以验证对会议的理解是一致的. 第一个人说第一个结论, 然后问其他的人是否同意还是认为结论另有其它. 说完之后第二个人说第二个…

要点在于参会人员不得参考任何资料, 只能依赖自己的大脑.

实践背后的原则

上面的一组极限会议实践, 背后其实基于两条原则: 以终为始, 保持张力.

  • 以终为始: 在最早的时刻就把候选结论抛出来, 后续的讨论只是对初始结论的修正. 任何跑题的讨论都通过命题调教或举例说明拉回来.
  • 保持张力: 方式很多, 暴露异议来PK, 减少必要信息供给来促进思考, 制定不利的初始结论来提升紧迫感.

组合运用这些手段可以得出更多的规则.

答疑

这么着急得出结论, 会不会有些话题没有足够的时间充分讨论而错过更多可能性?

丧失部分可能性是可能的, 但讨论是否充分, 跟时间长短没有必然联系, 更能影响讨论充分性的, 是看目的是否明确, 是否有备而来, 是否有足够张力让你调动大量脑细胞. 给你充足的时间反而放松了. 放松的环境, 随意的交谈或许有助于激发灵感, 但那不需要组织会议也可以创造这种条件.

另外不是每个规则都奔着”时间短”去的, 比如”留白”. 真正的关注点还是效率: 单位时间内更充分的沟通和理解.

有些建议是冲突的, 比如”一分钟结束会议”和”留白”

实践不只包含具体操作, 还包括场景及意图. “一分钟结束会议”和”留白”的场景及意图不同.

Share

工欲利其器, 必先善其事

标题没有写反, 意思是如果我们想要推行某种理念/实践/工具, 必须先帮助客户把事情搞定.

这并不新鲜, 通俗讲就是必须先赢得客户信任. 但并不是说不择手段, 今天讲的是考虑客户实际情况, 不要一开始就追求理想效果, 而是循序渐进, 采取的是不是”最标准最正确”的做法不重要, 只要比之前有进步, 让客户感觉到成效就是很好的基础.

这么说比较空洞, 看几个栗子.

某组织引入敏捷, 并请 ThoughtWorks 帮助其实施落地. 在开始几天的站会上, 团队成员通常就某问题的细节讨论了起来, 有问有答, 你来我往, 甚是热闹. 此时作为咨询师的你我, 该怎么做呢?  

依然在站会上, 同学 A 说昨天上午碰到一个问题, 想请同学 B 帮忙看看. 注意是昨天上午. 此时作为咨询师的你我, 该怎么做呢?

其实一开始我是拒绝这种情况的. 我会打断说, 细节问题下来再讨论, 也会语重心长的跟同学 A 说, 有问题要及时请教. 然而效果呢? 效果是过了一段时间之后, 团队说站会没用.

原因呢? 原因至少有两个. 一个是我们交给团队的关于站会的要点, 团队短时间内并不能完全领会, 站会只是简单汇报自己的工作流水账, 对其他人没有什么价值. 第二个原因更重要, 就是我们打断的, 中止的, 建议提前的, 那些沟通, 并没有发生.

客户的团队是不具备沟通的习惯的. 即使我们并没有参与客户之前的工作方式中, 也可以这样断言. 因为如果你经常沟通的话, 一定会在长期的练习中学会如何沟通, 哪些该详细哪些该简略, 如何让别人更容易理解. 可是我们并没有感受到这一点, 因此客户的团队之前是没有沟通的习惯的.

那么对于不具备沟通习惯的团队来说, 有个场合能让沟通发生, 让大家讨论起来, 就已经是进步了, 就已经很有效果了. 我们要做的, 是肯定这种效果, 并把它归功于我们引入的实践, 比如站会. 所以现在我会静静的等着大家讨论完, 然后关键的是站会结束后必要的引导:

大家刚才讨论了很多, 有多少人觉得有收获, 了解了之前不知道的信息, 比以前更清楚了? 

一般很多人都会点头. 再接着问:

是否对你今天的工作有帮助?

回答通常依然是肯定的. 然后就可以总结陈词了:

嗯, 我们就希望每天的站会大家都能获得一些新的信息, 请求队友的帮助, 减少后续工作的障碍. 挺好, 继续保持.

几次之后, 我观察到的现象是:

  • 团队很积极的参加站会, 到点就有人喊.
  • 讨论比较充分, 讲自己碰到问题的比较多
  • 而居然有人开始注意到时间问题, 效率问题, 团队其他人的相关性问题, 会主动出来调节说: 会后再单独讨论吧!

就算团队自己意识不到效率问题, 我们此时再说, 细节问题线下讨论, 等等, 团队也容易领悟和接受. 因沟通习惯已经有一定基础, 无论是外界引入的调整, 还是自我调整, 都不会是揠苗助长.

类似的栗子还有很多:

  • 故事墙建起来了, 但平时没人挪卡. 那就先站会上集体挪吧, 保证站会后任务状态是最新的, 团队成员都能看到距离迭代目标还有多远.
  • 用户故事的名头喊出来了, 但故事上没有用户价值. 那就先保证有从用户角度出发的 AC 和测试用例吧.
  • 回顾会议上问题很多, 那就先挑一个短期有效果的先做起吧.

如果你还担心, 日后有人质疑你当日的说辞, 那么你只需要开场时补上一句: 大家的做法有很多改进的空间, 但我们一步一步来…

抛弃了对自己在客户心中伟光正形象的顾虑, 我们会获得更大的自由, 对客户更有帮助.

Share

JavaScript语言中五种消除分支的方法

最近开始使用JavaScript. 回顾了一下这几天的代码, 发现圈复杂度为1. 30几个函数40多行, 超过两行的函数都很少 (当然那种当做对象来用的函数除外, 只说实际做事的函数. 不要小看这40几行代码, 完成了5个完整的具有用户价值的功能. JavaScript的表达能力不是盖的).

由于JavaScript具备一些函数式编程语言的特征, 写出没有分支没有显式循环的代码也属正常. 但实际上多数代码还是命令式的. 命令式风格也能写出圈复杂度为1的代码, 看看都用到了哪些技巧.

多态

这种技巧在<<重构>>里提过, 跟JavaScript没有多大关系. JavaScript对Duck Typing的支持, 使得多态更容易实现. 略过

Null Object Pattern

这个也跟JavaScript没多大关系. 具体到js, 简单说就是不要出现undefined和null, 总是赋初值. string赋””, 对象赋{ }, 等等, 可以少很多判断

Dispatch Earlier, or “Boolean Parameter Considered Harmful”

这也是一种语言无关的策略. 多说几句. 简单来说就是但凡在函数内部需要根据参数进行判断走不同分支的时候, 总应该存在一个更早的时机可以把执行路径分开, 从而消除判断. 或曰早一点分开也需要判断啊! 这是对的, 但这个判断可以由用户做出, 或者在程序的配置中做出, 而无需运行时逻辑. 举个简单的栗子: 用户点击网页对话框中的”确定”和”取消”时发给server端的请求应该如何设计?

一种是发送请求到如下URL: http://my.domain/some/question?agreed=1 或者 http://my.domain/some/question?agreed=0或者post的话同一个URL不同body. 如果是这种设计, 那server端必然有一个if来判断是确定还是取消. 可用户点击的时候已经做出判断了啊, 在程序中再做一次不是很多余吗?

另一种设计会利用用户的判断, 点击”确定”或”取消”的请求会被发送到不同的URL, 从而被路由到不同的server端的代码. 处理”确定”的代码无需关心用户点击的是不是”确定”, 因为只有用户点击”确定”后请求才会被送到你那里. 类似桌面应用不同的按钮关联不同的事件处理程序.

那会不会有代码重复? 有就抽出来呗.

JavaScript 对象是天然的分发表

只有这一条跟JavaScript有点关系. JavaScript对象就是以string为key的哈希, 而JavaScript中函数可以作为值, 也就是函数可以作为哈希的value. 这让JavaScript对象成了一个天然的分发表, key进去,函数出来, 不用任何显式的if/else/switch. 举个栗子:

即时聊天机器人, 根据用户的输入做不同的动作, 比如输入天气的话, 就去查询最近的天气并返回, 输入餐馆就查询附近的餐馆并返回

var response_generators = {
  weather: function( ) { query_weather_from_weather_service… },
  restaurant: function( ) { get_local_information… },
  help: function( ) { generate_help_menu… }
}

var reply = response_generators[user.input]( );

这种方式可消除显式的分支, 并且代码描述性更强. 但有变化发生时, 依然要打开修改response_generators.

利用underscore之类的类库消除循环, 包括循环中的break和continue

var evens = _.filter([1, 2, 3, 4, 5, 6], function(num){ return num % 2 == 0; });
=> [2, 4, 6]
Share

当谈论覆盖率时我们在谈什么?

80-20-Rule

代码覆盖率 vs. 测试覆盖率

代码覆盖率通常指跑完测试后, 由工具自动统计的在跑测试的过程中被测代码的覆盖率, 细分的话包括语句覆盖率, 分支覆盖率, 函数覆盖率等. 由于代码覆盖率可由工具自动产生, 采集成本非常低, 而又比较直观, 所以历来受到开发团队及管理者的欢迎, 有的组织甚至将其作为 KPI 指标之一.

然而围绕着代码覆盖率, 有很多有趣的事情, 尤其是将其作为 KPI 的时候. 你会发现, 长期在低位徘徊的代码覆盖率, 突然之间会有一个比较大的提升. 究其原因, 是开发团队在短时间内加了”测试”. “测试”是打引号的, 因为当我们近距离观察这些”测试”的时候, 会发现通常是调用了某个高层的入口函数, 因而牵出很多底层函数, 覆盖率就上去了, 然而, 没有一个断言(assertion), 或者是区区几个断言. 也就是说, 把产品跑了一遍, 但没有判断其行为是否符合预期, 而代码覆盖率突然就达标了.

尽管对于追求自我改进的团队来说, 不会这么掩耳盗铃, 代码覆盖率依然是有价值的反馈指标, 但这从侧面说明了代码覆盖率并没有表达出我们对于外部质量真正的关注点. 那么我们对于质量真正的关注点是什么呢?

是断言的覆盖率, 即测试覆盖率. 换句话说, 我们真正关心的是, 我们总共应该有多少测试用例/验收条件/检查点, 它们中有多少已经被覆盖了, 即做出了真正的断言. 但目前为止, 还没有工具能自动统计跑完测试后, 测试覆盖率是多少. 代码覆盖率仅仅是无法自动统计测试覆盖率时的一个替代品.

为了统计测试覆盖率, 需要准备分子和分母的信息. 分母是产品”完整”的测试用例列表, 分子是已经执行的测试用例列表, 包括手工和自动. 如果你关心测试覆盖率, 而手头又没有这两个东西, 就要开始准备了.

注1: 利用现有的 xUnit 测试框架, 可以在某种程度上得到测试覆盖率. 比如可以将”完整”的测试用例列表用 xUnit 的测试用例表达出来, 其中对于还没实现的, 设置为 ignore. 这样可以从最后的报告中看出总数, 和 ignore 的数量(当然如果你不做断言, 还是白搭). 现在更多的是借助管理工具甚至 Excel, 来手工维护”完整”的测试用例列表及状态. 如果你知道有更好的方式, 请告诉我.

注2: 前面”完整”的测试用例列表, “完整”一直打着引号, 因为这是一个无法证明的问题, 我们只能根据经验设计测试用例, 无法保证其完整性, 并且随着产品的开发, 这个列表也会动态更新. 至于如何让测试用例尽可能完整, 是组织应该投入的地方.

此测试覆盖率 vs. 彼测试覆盖率

基于前面的描述, 那么当我的测试覆盖率达到某个比较高的数值, 比如80%, 是不是我就可以比更低的数值比如20%, 对产品更有信心呢? 答案取决于你的测试用例的设计.

我们都听过80/20原则. 比如用户80%的时间在使用20%的功能, 20%的功能就可以支撑起用户最关键的业务场景. 那么, 如果80%的测试覆盖率, 覆盖的是那不常用的80%的功能, 而20%的覆盖率, 覆盖的恰恰是最常用最关键的那20%的功能, 那么, 你是否还像开始那样, 相信80%的覆盖率带来的安全感呢?

基于测试覆盖率很难达到100%这个前提, 基于我们的发布时间总是很紧张而又要保证质量这个前提, 我们必须投入精力, 做测试用例的价值分析, 挑选出最有价值的测试用例, 优先安排资源实现和运行.

如果团队的测试用例没有经过价值分析, 没有优先级划分, 那么这就是接下来马上应该做的事. 这牵扯到一个问题, 测试人员及测试技能的价值.

当我们谈论测试技能时我们在谈什么

最近几年随着自动化测试框架的流行, 评价一个人员测试能力的标准逐渐变成了是否能写自动化测试. 如果照这个标准, 所有的开发人员一夜之间都具备了合格的测试能力. 这显然是一个不成立的结论.

测试至少分测试用例的设计和测试用例的编写执行两部分. 自动化测试的长处仅仅在于编写执行. 使用自动化测试框架并不会自动让我们的测试更有效, 更完备, 更具洞察力. 而测试的有效性和完备性, 通常是我们更关注的. 然而遗憾的是, 通常组织中这方面的知识比较欠缺, 关注度不够, 技能交流较少.

如果我们交流测试知识时, 更多的是谈论 xUnit, RobotFramework等, 而不是等价类/边界值, 恶邻测试法/快递测试法, 关键路径分析等, 那几乎可以肯定我们遗漏了更重要的东西.

要在时间资源人力资源有限的情况下保证产品质量, 我们需要提高测试用例的设计能力, 价值分析能力, 安排合理的测试策略.

本文转自:http://liguanglei.name/blogs/2015/06/01/code-coverage-vs-test-coverage/

Share

为什么你的Scrum会失败?(二)

前文说了Scrum三种角色的错误姿势,现在来说一下四个会议。注意是乱序,先看showcase。

Sprint评审会议/Demo/Showcase

如何评价评审会议(或者叫Demo, Showcase)的效果? 我听过的答案有客户满意、或收集到了反馈等。这都不够,且不说客户满不满意本就不应是评审会议追求的东西,就是收集到了反馈,都不够。

那如何评价评审会议的效果? 唯一的评价标准是, 会后有没有对product backlog做出调整

如果每次showcase完product backlog都没发生变化,那恭喜我们,我们的计划和预见能力很完美,完全可以按瀑布的方式工作,没必要迭代交付了。客户或stakeholder需要了解, 他们对showcase负有给出反馈的责任和义务,找对真正关心产品或项目的人来参加showcase。

但往往团队倾向于show好的一面,直接点就是掩饰问题,这是本末倒置,会后皆大欢喜就是失败的会议,会后没有调整product backlog也是失败的会议。

Sprint计划会议: 实际上应该是分开的两个会

很多团队都会抱怨Sprint计划会议的冗长和低效。抛开开会的技巧不谈,根本原因在于Scrum把两个不同目的,需要不同参会角色的会议融为一体了。在它的官方指南里明确说了计划会议有两个topic: what 和 how。

IPM

对于what,即下个sprint要做什么,某种程度上是不需要开发团队参与的。PO应该根据stakholder的输入,从业务优先级上选出下个sprint的backlog。这个过程可称之为IPM, iteration planning meeting,应该在本sprint开始前进行,也就是推荐在上个sprint的末尾进行,开发团队的参与是可选的,PO完全可以一个人搞定或者跟业务方的stakeholder来商定, 具体如何取决于PO。

  • 你说还没估算呢,PO怎么知道要选多少? PO可以根据之前Sprint完成的story个数,多选几张,比如多出个20%的量。
  • 你说开发团队不参与的话,可能漏掉一些技术依赖项。我们还有下个会呢,开发团队有机会给出反馈。

说到底,估算和技术方面的依赖,不是决定优先级的很重要的因素,仅供优先级参考而已。

IPM结束后,PO手里有了一小堆下个Sprint要做的功能,可能比开发团队正常能完成的量多了一点。这堆功能将作为下个会议的输入,可以微调。

IKM

下个会议称之为IKM, iteration kickoff meeting,在本Sprint开始时进行,主要目的是PO和开发团队对这个Sprint的目标进行交互解释、答疑、达成共识。开发团队对优先级,验收条件的任何疑问都可以提出来,PO来解释或调整任务。对what没有疑问之后可以开始估算,如果你非要估算的话。估的时候就按优先级估,估到累积的工作量达到团队的capacity为止。

IKM的解释,答疑和共识,依然是what,而不是how。对于how,开发团队自组织讨论就可以了,不需要PO参与。开发团队也完全可以在领到任务开始做的那一刹那,由领到任务的一对pair自己讨论how就可以。

总结一下就是 PO自己搞定planning,PO和团队一起kick off,团队自己搞定how。IPM不占开发团队时间,IKM 2个小时足够,其它的讨论分散在开发过程中

每日站会: 关注接力棒, 而不是运动员

站会到最后是最流于形式的会议,没有之一。原因很多,而一个比较普遍的原因是大部分站会关注在了错误的点上,引不起团队成员共鸣。这个错误的点就是关注每个人都干了啥,今天要干啥。站会对于团队成员就成了一项考核,考核你工作量饱不饱满。每个人挖空心思表明自己没闲着,说完自己的就完事,也不管别人的。

那么站会正确的关注点是什么? 进度,障碍,新知,及是否要进行调整。关注接力棒,而不是运动员

每日站会是进度报告会吗? 你可能会说不是。我只能说: 当然是了! 开完会对当前进度是什么样子都不知道,这会也太浪费时间了,甭管是半小时还是仅有10分钟。 (你说我们有其它方式了解进度,站会关注在其它方面,那是另外一回事)

站会首先是进度报告会,区别在于是向谁报告,报告的目的是什么。站会是向整个团队报告进度,目的是寻求帮助,提供新知,为可能的任务调整提供真实的输入。站会是以天为周期的PDCA环中重要的一步,负责Check和提出Action。Check时检查点不在谁闲着谁没闲着,而在于过去这一天有哪些新的信息会影响到任务交付。

评价站会效果的唯一方式是,会后有没有根据会上的信息做出相应调整。不排除不需要调整的情况,但很少。换句话说,如果你站会后没有调整,那你的站会是极有可能没什么效果的。

Sprint回顾会议

没什么可说的。只要回顾会议有效果,其它问题再大都是小问题。当回顾会议没有效果的时候,问题就大了去了。其它问题都可以在技巧层面针对问题本身改进。但回顾会议没效果的话,改进回顾会议本身是没有用的。

评价一项活动,不是看它过程,甚至不是看它结果,要看它对其它事务的影响。站会/回顾/评审会议,都涉及调整。开完会没什么调整, 会就白开了。

Share