产品经理和开发团队的关系

Bob Jiang
产品和技术之间的关系 今天微信有个朋友来咨询一个问题: 姜老师,请教个问题。现在很多公司喜欢把技术和产品分开作为平级。产品团队负责出需求,技术团队只负责实现需求。这种方式我感觉对市场导向的产品会出现需求和实现严重脱节…怎么解决这个问题呢? 回答:首先从问题的提出者来看,他已经意识到问题了 – 需求提出和需求实现严重脱节。 在解决这个问题之前,先澄清一下在敏捷开发(尤其是说Scrum)中,需求存放在产品列表(Product Backlog)中。那么一个好的产品列表,以及其中存放的需求(常常以用户故事格式呈现)需要具备以下特征。 用户故事的5C生命周期: Card Conversation Confirmation Construction Consequence 参考我之前的博客。 这里的前面3个C,更多指的是产品负责人和开发团队之间的互动。 我们可以说产品负责人(大多数公司仍然叫做产品经理,实际上他们是没有权利的)的最重要职责就是决定做什么和不做什么 – 排序产品列表。而对于开发团队(不仅有开发、还会包含测试,这里的开发团队指的是产品开发的团队),最重要的职责就是在迭代内实现产品列表。 在整个的迭代过程中,产品负责人和开发团队应紧密协作。而不是产品负责人只负责写出需求(用户故事),然后转给开发团队。 如何紧密协作 操作1 - 产品负责人面对面和开发团队一起讲需求 操作2 - 开发团队在动手写代码前,把理解的需求讲给产品负责人听 很简单的2个操作,就可以帮助到你的团队和产品负责人。 要不要试一下? 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处! 关于作者 BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区(hiblock.net)发起人 中国北方的第一位CST(Certified Scrum Trainer) 敏捷变革中心(Center for Agile Transformation)合伙人 敏捷一千零一夜社区合伙人 《Scrum精髓》译者 Bob的博客 Github: bobjiang Twitter: @bobjiang123 Solidity中文文档

你看到的世界不是真实的世界

Bob Jiang
你看到的世界并不是真实的世界 你以为你看到的世界就是真实的世界吗? 假设这样一个场景: 在一个拥挤的停车场里,你正在慢慢开找车位。你发现前方不远处有一个空车位,正在你准备开过去停车时,突然飞速开过来一辆车一头扎进去占上了。 请问此时你怎么想? 这个车位是我先来的,他在抢我的车位!该死的! 正当你要去理论的时候,对方车上下来1名中年男子,扶着一位怀孕待产的妇女。看样子是去旁边妇产医院的。此时你又是怎么想的? 或许你的想法有所改变。 但这就是真实的世界吗? 答案明显不是。真实的世界永远也无法完全搞清楚,只能是随着我们了解信息一点点增加,而扩大我们对于世界的认识。 犹如上述的这个例子,当你身处其中,并得知的信息越来越多时,世界的边界开始扩大。 最后回归到学习。我们学习的目的同样是为了更好的了解这个世界,从而能够接触到更多的可能性。 下面有几个你可能需要的微信群,或公众号。 Scrum精髓读书群 扫描二维码,并回复“scrum” 我有一个梦想 加入邮件列表 扫描二维码,并回复“dream” 加入微信群 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处! 关于作者 BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区(hiblock.net)发起人 中国北方的第一位CST(Certified Scrum Trainer) 敏捷变革中心(Center for Agile Transformation)合伙人 敏捷一千零一夜社区合伙人 《Scrum精髓》译者 Bob的博客 Github: bobjiang Twitter: @bobjiang123 Solidity中文文档

从困境走向成功

Bob Jiang
从困境走向成功 北京今天天气晴朗,是个好天气,适合多读书。 今天推荐一本引导工具书 – 《从困境走向成功》 本书以小说为题材,由浅入深的介绍了: 实效的团队方法 深度沟通的团队方法 复杂冲突的团队方法 最后还介绍了CSA(Clarity, Solution, Action)工作坊的模型与设计。 实效团队方法 在实效团队方法中,介绍了几个很实用的引导方法,我也在培训中经常用到的: me we us – 个人先梳理观点、想法,然后小组整合,最后课堂梳理出结果 艺术画廊 – 适合提出问题,由大家的双脚法则来决定他们想工作于哪些问题上 深度沟通团队方法 这里介绍的两个方法是比较复杂(需要一定引导基础)的,如: 欣赏式探询 – 基本概念来自于同名书籍。 欣赏式探询 世界咖啡 – world cafe 复杂冲突团队方法 开放空间是另外一个很复杂的引导方法(或心态),参考资料。书很薄,容易阅读,但是要掌握还是很不容易的。首先从心态上要能接受各种变化,其次结果也往往会和预期不一样。 最后附上一篇 开放空间与世界咖啡馆 的对比。 思考 引导是Scrum Master必备的一项能力,也是培训师的一项利器。尤其在设计互动工作坊的时候,非常考验引导的能力。这是一本以介绍工具为主的引导书,可以很容易的先了解一些基础工具(每个工具介绍的并不足够详细)。如果想要深入了解,建议去阅读其他引导书籍,如《引导 : 团队群策群力的实践指南》《引导的秘诀 : 通过团队合作获得结果的SMART指南》等等。 引导,从我个人的经验来看,知道概念很容易(入门简单),想要精通就必须经过大量的实践、总结。 每日问题 你本周读了哪些书,可以留言推荐一下。 广告时间 订阅邮件列表 - 我有一个梦想 和BoB面对面学习Scrum 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处!

你在变成连自己都讨厌的人吗

Bob Jiang
你在变成自己讨厌的人吗 昨天在朋友圈看到一个朋友的分享: 我开车的时候最讨厌两种人: 1. 强行加塞的人; 2. 不让我强行加塞的人 首先我也有同感,我也是这样的想法。 后来我越想越不对哈,为什么呢? 假设我有分身术,分出一个Bob’ (原身是Bob)。 Bob在开车,直行道前进中。这时Bob’在右侧强行加塞。 那么此时,Bob讨厌Bob’(因为讨厌1. 强行加塞的人);而Bob’也讨厌Bob(因为讨厌2. 不让我强行加塞的人)。 结果就是自己讨厌自己啦! 原来自己开车的时候,这么令人讨厌!已经都是自己讨厌自己了! 我可以做出什么改变 为了不让自己讨厌自己,我决定: 不去强行加塞 让强行加塞的人 开车的目的是为了快速到达目的地,并不是与人较劲。 希望看了这篇文章的同学,也能一起做出一些些改变。 你愿意改吗? 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处! 关于作者 BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区(hiblock.net)发起人 中国北方的第一位CST(Certified Scrum Trainer) 敏捷变革中心(Center for Agile Transformation)合伙人 敏捷一千零一夜社区合伙人 《Scrum精髓》译者 Bob的博客 Github: bobjiang Twitter: @bobjiang123 Solidity中文文档

市场的基本原理

Bob Jiang
市场基本原理 市场的基本组成是买方和卖方,即供需关系。 现存的经济中,最主要的2大分类是: - 市场经济 - 计划经济 市场经济 市场经济,亦称资本主义经济或者自由企业经济,是人类协作的扩展秩序。其特色是私人拥有资本财产(生产资料),且投资活动是由个人决策左右,而非由国家所控制。借着雇佣或劳动的手段以生产资料创造利润。商品和服务借由货币在自由市场里流通。投资的决定由私人进行,生产和销售主要由公司和工商业控制并互相竞争。一般普遍认为市场经济在西方世界的封建制度崩坏之后成为了最主要的经济模式。 理论上,市场经济是自由的经济、公平的经济、产权明晰的文明经济。但实际上,纯粹的市场经济因具有盲目性、自发性等弱点,在实际操作中显示出缺陷,这需要科学的宏观调控来解决。 计划经济 计划经济(英语:Planned economy),又称统制经济或指令型经济,是一种经济体制,在这种体系下,国家在生产、资源分配以及消费等各方面,都是由政府事先进行计划。“指令型经济”通常和计划经济用法相同,但是详加区分的话,指令型经济是指生产工具公有的经济体制。所以指令型经济必定是计划经济,但计划经济却不必然为指令型经济。 除了以上两种经济形态,其实还存在第三种,混合经济。也就是说部分的市场经济加部分的计划经济。 目前区块链中有一部分人在追求的是完全市场经济,不过这个本身就不可能存在。就和这个理论本身一样,不存在完全的。(比如不会有哪个政府支持武器、毒品的自由买卖) 总结 存在供需关系就存在市场,就会有市场行为。 有一句广告词,没有买卖就没有伤害。 其实想要说明的也是这个道理。 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处! 关于作者 BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区(hiblock.net)发起人 中国北方的第一位CST(Certified Scrum Trainer) 敏捷变革中心(Center for Agile Transformation)合伙人 敏捷一千零一夜社区合伙人 《Scrum精髓》译者 Bob的博客 Github: bobjiang Twitter: @bobjiang123 Solidity中文文档

使用谷歌Google的小窍门

Bob Jiang
你会用谷歌吗? 作为互联网一代,每天我们都在用各种搜索。查一个商品价格,查一个学习资料,查找一个工作中遇到的问题,等等。 最好用的搜索引擎,莫过于谷歌(Google)。 在国内,我依然建议每个人去学会如何使用谷歌,可能科学上网是第一个你需要解决的问题。 点击这里查看科学上网的方法之一 谷歌搜索引擎的窍门 使用标签 默认搜索用的是全部,还可以单独搜索视频、图片、新闻、购物、图书、地图、航班、财经等。 使用双引号 默认的搜索谷歌会自动拆词。如果你想搜索的是一个完整的句子或短语,可以用双引号括起来。 使用减号 比如搜索关键词敏捷,但不想查看测试相关内容。那么可以用如下方式进行搜索: 敏捷 -测试 用冒号搜索指定网站 如果想要在特定网站搜索内容,可以用如下方式: keywords site:website.com 比如 敏捷之旅 site:bobjiang.com 使用星号 星号(*)可以匹配任何内容,常常用来搜索歌词。比如某首歌曲,只记得其中部分歌词,其他部分用星号代替。 用叙述句 尽可能用叙述句而不是问句。 全部原文 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处! 关于作者 BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区(hiblock.net)发起人 中国北方的第一位CST(Certified Scrum Trainer) 敏捷变革中心(Center for Agile Transformation)合伙人 敏捷一千零一夜社区合伙人 《Scrum精髓》译者 Bob的博客 Github: bobjiang Twitter: @bobjiang123 Solidity中文文档

为什么敏捷不提倡子团队

Bob Jiang
为什么敏捷中不提倡子团队 Scrum中的开发团队,鼓励是 feature team 特性团队。下面我们来分析一下原因。 为什么是特性团队 我经常会讲到,组织中用什么结构都是可以的。组织结构是为组织目标服务的。 原来在老东家(JD)的时候,公司内流传这样一句话:3个月小调,半年大调。说的就是组织结构。 特性团队的定义是: A feature team is “a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.” Feature teams are an essential element to scaling up agile development. Without a feature team structure (but instead, a component team organization—based on code ownership, combined with a single-function organization—analyst group, programmer group, testing group, …) your organization is likely to create numerous wastes and sub-optimizations that lead to a sequential (waterfall, …) development cycle.

不要推敏捷

Bob Jiang
不要推敏捷 推还是拉,在专业的敏捷教练眼里答案很明显。 从上图我们可以看出来,如果是一个系统由多个子系统组成(常常是这样的),推很容易导致 1) 子系统很难对齐 2) 各子系统的抗拒。而相反,如果采用拉的方式,则上述两个问题很容易得到解决。 所以推还是拉,答案是明显的(当然是拉)。 敏捷转型是需要推还是拉 既然答案已经这么明显,不论是敏捷转型,还是其他系统,都是应该采用拉动的方式。那么现有的大多数公司,推广敏捷(或者就叫做推敏捷)显然会碰到上述的问题与抗拒的。 我们只列举问题,不解决问题是不好的。那么如何拉动敏捷转型。 拉动组织的敏捷转型 首先,需要敏捷转型的目的。如果转型目的只是为了一个kpi,或者某个老板的喜好。麻烦你,可以该干嘛干嘛去了。敏捷转型的目的,一定要围绕着组织目标(更大一点,公司目标)来进行。比如公司当前的业务收入有问题,那么转型的目标就围绕着如何提升公司收入。 其次,管理层(决策层)要行动起来。公司的前进是需要火车头的带动,这个火车头就是公司的管理层。如果公司管理层只是口头上支持敏捷转型,而行为不发生任何变化,依然不会有什么太好的结果。例如,组织结构不发生任何变化,老板仍然是随时打断开发团队,或者老板随意插入需求等等。(总之,老板或管理层是需要做出表率) 最后,团队需要了解Scrum的框架。(我指的是真正的Scrum,而不是伪造的)因为很多宣讲敏捷的老师,都在把团队往火坑里面推。想要了解真正的Scrum,欢迎关注Bob的敏捷认证课程。 写在最后 请不要再说推(广)敏捷。你可以做的事情有很多: 思考一下,组织内有哪些地方不顺。 或者组织内哪些地方总是需要协调。 团队内,有什么工程实践,工具可以显著提高团队能力 总之,有很多有意义的事情可以做,不要总是打着推敏捷的旗号,卖狗肉。 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处! 关于作者 BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区(hiblock.net)发起人 中国北方的第一位CST(Certified Scrum Trainer) 敏捷变革中心(Center for Agile Transformation)合伙人 敏捷一千零一夜社区合伙人 《Scrum精髓》译者 Bob的博客 Github: bobjiang Twitter: @bobjiang123 Solidity中文文档