人工智能趋势简报 2025
AI 正以前所未有的速度普及和变革全球产业，用户增长迅猛，企业和政府资本投入激增，驱动自动驾驶、机器人、医疗、金融等领域创新爆发。AI 正演变为新型基础设施，尽管面临高成本和盈利挑战，未来增长潜力巨大。
2025/6/8
articleCard.readMoreB
Bob Jiang 敏捷开发培训 敏捷认证Scrum Master
Recent content on Bob Jiang 敏捷开发培训 敏捷认证Scrum Master
Rich Robot Behaviors from Interacting and Trusted LLMs - A Beginner Guide
This paper explores using interconnected Large Language Models (LLMs) to control robots, focusing on ease of use, transparency, and safety. It introduces a system where multiple LLMs communicate using natural language, enabling humans to easily understand and modify robot behavior. The system incorporates blockchain technology to store and enforce rules, ensuring robots are aligned with human values.
2025/5/8
articleCard.readMore悉尼搬家经验总结
在悉尼, 搬家不是一件容易的事情。 或许在哪里, 搬家都是很困难的.
2024/5/28
articleCard.readMoreMonad 101 - Monad is a high-performance Ethereum-compatible Layer 1 blockchain.
tl;dr Monad is a high-performance Ethereum-compatible L1. Monad materially advances the efficient frontier in the tradeoff between decentralization and scalability. Monad introduces optimizations in four major areas, resulting in a blockchain with throughput of 10,000 transactions per second (tps). MonadBFT Deferred Execution Parallel Execution MonadDb advantages of Monad Monad, a new Layer 1 blockchain, differentiates itself from other blockchains, particularly EVM-compatible ones, through several key strengths: High Transaction Throughput: Monad can process up to 10,000 transactions per second (TPS) thanks to its innovative parallel execution and MonadBFT consensus mechanism.
2024/5/21
articleCard.readMore世界上最强大的力量是什么？
摘录自网络国家, 第二章
2024/5/14
articleCard.readMore悉尼租房经验总结
本文描述个人在悉尼的租房经验。
2024/2/26
articleCard.readMore悉尼买房个人经验总结
本文描述个人在悉尼的买房经验，从2023年初开始看房，直到年底出手。中间经历了3次大的转折，也经历了好几个意外。分享给大家。
2024/2/14
articleCard.readMore悉尼的衣食住行（半年总结篇）
移民半年后的一篇小结，主要是生活方面包括衣食住行等
2023/7/1
articleCard.readMoreBob's Experience in GitcoinDAO
My experience in GitcoinDAO I had 2 posts to introduce what is DAO and what is GitcoinDAO. If you’re a newbie for DAO and GitcoinDAO, please refer to above articles. In this post, I would like to tell my real experiences in GitcoinDAO. I started the GitcoinDAO life since July 2021. For now my role is the user support lead, here is homepage for GitcoinDAO user support. I met Gitcoin in 2018 when I joined crypto at that time.
2022/3/30
articleCard.readMoreWhat is Decentralization Autonomous Organization (DAO)
What is Decentralization Autonomous Organization (aka DAO) In this post, I will introduce what is DAO, and I will introduce how to start a DAO in next post. So here is a definition from Aragon - - Member-owned communities without centralized leadership. - A safe way to collaborate with internet strangers. - A safe place to commit funds to a specific cause. DAO definition on Ethereum.org So let’s go into details about DAO from 3 perspectives:
2022/3/29
articleCard.readMoreWhat is GitcoinDAO
What is GitcoinDAO Gitcoin is a Decentralized Autonomous Organization governed by the holders of the GTC token. Token holders delegate their votes to a trusted steward. Some choose to self delegate. The stewards then accept or decline actions by voting for proposals which pass quorum. Official proposals and formal conversations on governance can be found on the Governance Forum Informal conversation about workstreams, and idea sharing happens in **Discord** Checkout the documentation about the GTC/GitcoinDAO smart contracts.
2022/1/29
articleCard.readMoreBob Jiang 2021 summary
Financial Here is my 2021 financial report (simple version) without revenue from investment. - financial - agile training $150k - crypto salary $33k - crypto airdrop $30k - no include investment (like ETF and crypto investment) So from the financial report, my major incoming is still from Agile training, (60%) which is not what I want. I will work out new plan for 2022 for the incoming structures. Work Agile/Scrum I have different work for now, one of is Agile training as I am Certified Scrum Trainer from scrumalliance, so I could train the Certified Scrum Master (CSM) for individuals or organizations.
2021/12/26
articleCard.readMoreOpen Source insights
beginning I am Bob Jiang (bobjiang.com) , a new guy in open source software. I started to know and learn open source since 2018 when I joined blockchain area. At that time I founded HiBlock community, my goal is to promote blockchain technology in China. So I start to learn Bitcoin, Ethereum, smart contract etc. In blockchain, the open source is standard. The famous quote is: Don't trust, verify it!
2021/12/17
articleCard.readMore如何在一年内构建8300万客户社区（译）
本文是来自twitter上的一个系列推文，描述的是一年的时间通过社区方式获得了8300万客户。非常值得学习一下，尤其是对于区块链产品。
2021/2/22
articleCard.readMoreBob Jiang 周报202107
2021年 Bob Jiang周报
2021/2/21
articleCard.readMoreBob Jiang 周报202106
2021年 Bob Jiang周报
2021/2/14
articleCard.readMore免费搭建个人博客详解 | Bob Jiang博客详解
每一个互联网人一定需要一个博客，博客相当于你在互联网的家。我们在生活中都有一个家；而在互联网上，你也需要有一个门牌号（域名）和你的家（博客）。2021年了，你有开始在互联网上搭建自己的家吗？种一棵树最好的时间是10年前，其次就是现在。
2021/2/12
articleCard.readMoreBob Jiang 周报202105
2021年 Bob Jiang周报
2021/2/5
articleCard.readMore什么是敏捷开发
敏捷开发自2001年提出敏捷软件开发宣言后有20年，但在中文里很少有一篇文章详细介绍敏捷开发。因此本文从敏捷开发，敏捷开发的历史，敏捷开发的分类，敏捷宣言（价值观），以及敏捷精髓等方面详细阐述了敏捷开发。本文的最后还列举了敏捷在除了软件行业以外的应用，比如硬件、人力资源、市场、等等。
2021/2/4
articleCard.readMoreBob Jiang 周报202104
2021年 Bob Jiang周报 第4周
2021/1/30
articleCard.readMore详细介绍Scrum Master八大职责（Scrum Master能力说明）
Scrum Master这个角色的职责很多人一直在困惑着，本文从八个方面详细介绍了Scrum Master的职责。作为Scrum提出的全新角色，他和传统的角色不一样，主要包含了以下职责：服务型领导，引导者，管理者，教练，导师，教师，清道夫，变革大师。本文还阐述了几种常见的Scrum Master职责的误区，看看你中招了吗？
2021/1/27
articleCard.readMore团队还需要Scrum Master吗？ - 在团队成熟之后
随着团队对于Scrum越来越熟悉，Scrum Master的工作也慢慢变少了。所以很多人都会有一个疑问，我们还需要Scrum Master吗？ 尤其是团队成熟之后，全职的Scrum Master是否有用？
2021/1/26
articleCard.readMore提问的艺术 - 敏捷教练技巧
提问的艺术 - 本文通过一个虚构的故事讲述了Scrum Master工作中提问的技巧和艺术。然后详细阐述了什么是有力的提问和无力的提问并给出了具体例子及进行了对比，最后还为Scrum Master和敏捷教练提供了一个有力的提问检查表给大家使用。
2021/1/23
articleCard.readMoreBob Jiang 周报202103
Bob Jiang周报 2021年第3周
2021/1/22
articleCard.readMore如何安装旧版本的node 在新芯片M1苹果
本文记录了自己如何在苹果M1芯片的笔记本上安装旧版本的node (node v14.10.0) 主要分为以下几个过程： 脚本安装 nvm，不要用brew安装 设置 zshrc 环境变量 安装旧版本 node 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash 参考 nvm github repo 修改环境变量 nvm 安装后默认更新的是 bash 环境变量。MacOS很多采用的默认 zsh 因此把 bash 中关于 nvm 的变量部分，增加到 .zshrc 中 vi ~/.zshrc export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion 安装旧版本 node # start a shell under Rosetta 2.
2021/1/20
articleCard.readMoreSpotify 团队健康检查模型
团队是否是健康的？如何定义一个团队的健康度，本文是Spotify内部的一个示例，可以作为自己团队健康检查的一个起点。欢迎分享和使用。
2021/1/19
articleCard.readMoreSpotify的大规模敏捷之路—使用一种新型的矩阵组织：部落、分队、分会和协会
Spotify 规模化敏捷的实践，不仅有组织结构的描述，还有具体实践。如果想要学习 Spotify 的敏捷，这是第一篇地点。随手分享给你的朋友 ：）
2021/1/19
articleCard.readMoreScrum回顾会实践
回顾会是敏捷中的核心，是帮助团队回顾反思的正式机会。如果你的团队还没有掌握回顾会的精髓，那么就非常值得反思。开始帮助团队建立起定期的反思机制吧。
2021/1/18
articleCard.readMoreSprint评审的误区 | 真不是演示会 demo show
Sprint评审会不是演示会，不是演示会，不是演示会。演示会（demo）仅仅用于演示，而忽略了适应和调整。请采用正确的术语来帮助团队建立正确的Scrum框架使用方法。
2021/1/18
articleCard.readMore免费发布自己的https ssl证书 | 阿里云收费https服务应对方案
阿里云静态网站上如何使用自己的https证书。为自己的二级域名发布免费的https证书。
2021/1/18
articleCard.readMoreScrum Master是项目协调人？ | Scrum的误区
Scrum Master这个角色是项目协调人吗？在组织内是多余的人吗？Scrum Master到底是做什么的呢？本文详细解读了Scrum Master这个角色。
2021/1/16
articleCard.readMore规模化敏捷之前，应该先做好这件事！
企业越做越大，敏捷也要求规模化。虽然敏捷从一开始是小团队，但依然可以适用于多团队的。不过这个时候要十分小心规模化的方法和方式……
2021/1/16
articleCard.readMoreBob Jiang 周报202102
2021周报 week 2
2021/1/15
articleCard.readMore你是哪种管理风格？微观管理还是……
本文用一个生动的故事来描绘了3种不同的管理风格。故事来自于一个虚构的村庄，当你处在这样一个场景下，你会如何进行交通管理？对应于工作中，处于类似的场景下你会如何管理呢？是微观管理还是大妈管理还是专家管理？
2021/1/9
articleCard.readMore敏捷的目的（方向）错了以后……
Scrum之类的框架非常适合解决业务问题，并且公司不断过渡到敏捷以实现目标。但是，如果他们忘记了敏捷只是一种方法论（一种实现目标的手段）而不是目标本身，就会出现问题。 斯科特-邓恩（Scott Dunn）写了一篇很棒的文章，讲述了与管理层突然”变得敏捷”的决策有关的陷阱（和恐惧）。它反映出它是一个简单的实现方式（如更换供应商），而不是一个需要在观念上进行重大改变的框架，这是一种错觉。 “亚马逊正在这样做。” 这些都是很好的指标，表明企业尚未明确定义为什么要使用敏捷，以及”为什么？” 与公司合作过渡到敏捷或教学认证的Scrum课程时，这是我首先要提出的问题之一。 我经常得到诸如以下的答案： 我们想迅速适应变化 我们要不断改进 我们想更定期地交付 从表面上看，这些听起来像是伟大的目标，并且与我们从敏捷方法学中期望的结果一致。 但是，即使你没有明确定义目标，但即使听起来不错的目标也会引起问题和挫败感。 你怎么知道你选择了正确的目标？ 假设我的朋友告诉我他想在未来12个月内再赚10万美元。我可能会鼓励他对这个目标进行压力测试，看看这是否是他真正想要的。 “五个为什么”是一种发现问题的根本原因的公知方法，它也可以很好地发现追求目标的根本动机。 如果我问我的朋友为什么他要这10万美元，他可能会回答说这是为了改善自己的地位，或者他说他想彻底改造自己的房屋。 如果我们再加上一个”为什么”，我们可能会发现更深层次的关于这些事情对他而言重要的内容。然后他可能会说地位对他很重要，以向他的父母证明他的成功。或者，他想进行改造，以便能在一天工作结束时回家会很高兴。 当你继续研究为什么某些重要内容时，你可以开始回顾最初的目标并提出以下疑问：这是正确的目标，并且定义明确吗？ 例如，也许我的朋友不需要10万美元就可以向父母证明自己成功了，也许他只需要一些生活指导就可以意识到自己足够好。也许他一天结束以后想要回家所需要的所有东西都是问候他最好的朋友。 一个好的目标也需要好的指导方针 经过一番讨论，我的朋友决定他绝对想要的就是现金。 他应该如何实现呢？ 他可以抢银行。或通过庞氏风格的加密货币骗局获得资金。 他应该考虑那些选择吗？ 好吧，由于我的朋友不是犯罪策划者，所以他很有可能会被抓住并失去自由。他也是一个非常体面的人，所以犯罪的想法可能会让他不高兴。 大概不是。 显然，我们认识到，除了选择正确的目标之外，他还需要想一下如何实现该目标（例如不违反法律）以及不损害对他来说很重要的事情（例如他的自由和价值观）的指南。 当你有正确的目标，但执行错误 我认识一位高级副总裁，他想利用Scrum改善协作。 对于这种敏捷框架而言，这是一个完美的目标。但是，他还认为，只有团队实际合作才能实现协作。结果，他把每个人都搬进了一个狭窄的小房间，并坚持所有的工作和讨论都在那儿进行，整个团队都参与其中。 这不仅不舒服；这也意味着以前在家里工作了几天的一名会员现在每天要往返三小时。 士气和工作质量开始受到影响。当我进来看看为什么敏捷对他们不起作用时，我首先问他为什么要改善协作。 他告诉我，他希望团队成员： 了解其他人在做什么，找出差距，或查看成员在哪里过度工作，以便他们可以互相帮助 自信而迅速地讨论问题的解决方案 以简单明了的方式相互交流 而且我们意识到，这些东西实际上都不需要任何人坐在别人旁边。 副总裁再次审视局势，意识到”协作”并不意味着必须坐一起，而且我们能够重新审视他们为实现实际目标而可能采取的不同方式。 当你忘记原因时，很容易被分裂 我与一个刚加入团队的Scrum Master一起工作。当她发现他们修改了一些规则时，在她眼中，他们没有正确地执行Scrum。作为Scrum Master，她觉得纠正团队，确保每个人都以正确的方式做Scrum是她的职责。 为此，她仔细研究了规则，强调了团队的错误并建议他们应该怎么做。但是她推得越多，推倒的人就越多，这变成了无休止分歧的有害环境。 我问她为什么强制采用这些工作方式如此重要。她回答： “因为那是我以前与以前的团队一起工作的方式，所以我们真的很成功。” 我请她描述该团队的情况，并分享她为什么认为他们在一起表现很好。 “我们做到了。即使我们犯了错误，我们也是彼此的啦啦队。我们知道彼此的长处，我们从不担心踩脚，我们真的很乐意进去并尽自己最大的努力。” 当我们退后一步时，我们发现她对规则的严格性造成了紧张、不信任和生产力下降。她的总体目标是成为一支高效能的敏捷团队，但她的短期行动与之直接冲突。 如果你想避免类似的敏捷问题，请参考以下建议： 压力测试目标并确保目标明确 如果你的组织正在向敏捷过渡，请鼓励经理在可能的情况下对这些目标进行压力测试。保持好奇：找出真正重要的内容。消除歧义性与团队协作所要实现的模糊性，这样你就可以通过自己的方法来发挥创造力，而不是被任意的规则所束缚。 考虑一下你愿意支付的费用，以及你不会受到损害的地方。团队士气重要吗？吸引更少的客户以实现承诺，提供更可靠的服务并建立更多的重复业务是否更好？ 在团队层面追求目标 我最喜欢的非敏捷书籍之一是Daniel Coyle撰写的《文化守则》。在其中，他研究了使某些团体成功的因素，并向领导者展示了如何建立凝聚力、积极进取的文化。在运动队中，他发现成功通常与团队成员做出的许多无私的传球有关，与个人如何将团队的成功置于个人荣耀之上。 我认为成功的敏捷团队也会发生同样的事情。与我一起工作的一个团队按时交付，但显然设计师天天加班。成员在计划和挑选任务时没有考虑自己的个人能力，而是开始考虑团队能力。他们认为，如果一个人在挣扎，他们会都很难受。开发人员放弃了自己的一些积压项目，花一些时间学习设计并尝试提供帮助。团队在短期内降低了速度，但从长远来看，由于他们拥有更加广泛的技能，他们开始提供更多的东西。如果他们只是专注于在每次迭代中提供尽可能多的功能，那么这种长期的进展可能永远不会发生。 敏捷是否在帮助你实现目标？ 我希望知道你的经历。目标是否明确定义和理解？还是你曾经觉得自己正在遵循以流行语为基础的商业计划？使用Scrum和敏捷解决业务问题或实现目标时，你发现什么效果很好？ 所有你的敏捷是怎么样的呢？ 是否有关注到最终目标呢？ 敏捷转型过程中你还有哪些困惑呢？ 欢迎留言讨论……
2021/1/9
articleCard.readMoreBob Jiang 周报202101
2021第一次周报，以及2021立的flag。
2021/1/8
articleCard.readMore敏捷环境下如何写文档之反模式 | 论只写有用的文档
简单说就一句话，敏捷文档的特点是易于使用且易于更新。 精简文档的目的是帮助你（作为读者）找到问题的答案，而不是自己掌握详细的答案。涉及到IT系统和代码的文档时，尤其如此。代码本身应该是该问题的最好答案。文档应仅帮助指引寻找答案的方向。 打个比方，一本书的内容好比是代码，好的文档就是这本书的目录，而不是本书的摘要。目录非常简短且易于阅读，并且更新频率很低。目录通常是分层的（比如部分、章节、小节），这样查看会更快。 接下来我们看一些文档的反模式。 反模式＃1 – 没有文档 在许多组织中，没有文档是最常见的反模式。经常发生这种情况是因为他们没有阅读或错误解读了”敏捷宣言 ”的一部分， 其中说：”尽管右项有其价值。” “无文档”的相近模式是”随心所欲的文档”模式。我们还是用书的类比，没有任何文档说明你需要阅读和记住整本书（因为没有目录），才能知道在哪里能找到问题的答案。这种反模式的后果是人们需要花费很长的时间才能进入工作。这会导致信息孤岛、组件团队、局部优化、扩展困难等问题。 反模式2 – 过于详细文档 为了克服反模式＃1，一些组织认为，详细的文档就是答案。还是用书的类比，这就像写本书的摘要。问题是随着书的内容不断更新，要保持摘要更新需要大量的工作。而且一旦不更新，就无法再使用了。这意味着情况与反模式1相同。 反模式3 – 需求作为文档 这是一种奇怪的文档类型，但是某些组织将有关功能需求的详细信息保存成文档。问题在于这些需求只是增量，即系统中一个状态与下一状态之间的差异。要了解当前状态，你需要构建全部。如果这些增量中有丢失，则说明文档（需求文档）不受信任。这可能比没有文档更糟糕，因为这只会使读者感到困惑。
2021/1/6
articleCard.readMoreScrumMaster也是人 | 敏捷联盟2020年十大博客
有很棒的Scrum Master，也有糟糕的Scrum Master。 还有伟大的经理、开发人员、测试人员、销售人员、邻居，也有糟糕的。人就是人–无论他们的职业或生活角色如何。 Scrum Masters也是人。就像每个职业一样，大多数人会随着时间和经验的增长和进步。有些成长比其他成长更快。 您是否有因为Scrum Master尚未消除障碍而继续困扰您的团队的障碍？还是团队内部或团队外部的沟通不畅，并且阻碍了您完成工作的能力？也许您觉得您的团队陷入了困境，而您的Scrum Master似乎对此无能为力。如果您的Scrum Master不是您希望的那样，您会怎么做？ 首先，希望您的Scrum Master不断成长。请记住，您在某些时候也是开发人员的新手或测试人员的新手。早期，您可能编写了糟糕的代码，却错过了关键测试。了解您的Scrum Master最终会更好地指导Scrum的采用和成长，自我组织以及障碍的消除。但是这需要时间，就像您成为当今的开发人员或测试人员需要花费时间一样。 接下来，向他们伸出援助之手。你是怎样做的？这里有六个想法： 在出现问题时大声说出来 在地毯下隐藏问题根本无济于事。透明度是高绩效敏捷团队的主要优点。但是在提请注意问题时要谨慎。有些事情最好私下提出，特别是如果这对于Scrum Master来说是一个缺点。 鼓励您的Scrum Master 优秀的Scrum Master经常鼓励其团队。但是谁鼓励Scrum Master？当您发现Scrum Master为团队提供了帮助时，请让他们知道很感激。是的，这是他们工作的一部分，但我们每个人都需要时时给予鼓励。 与Scrum Master头脑风暴 花一些时间思考可能导致问题的原因，并与他们合作提出创新的解决方案。没有人能回答所有问题。两个头脑总是比一个头脑好。 别装作自己懂 有时沟通不清晰，或者需求没有明确定义。单纯基于假设前进是危险的，并可能造成障碍。Scrum Master可能不得不花费不必要的能量清除障碍。保持谦卑，提出问题，并确认您的假设。 请您的Scrum Master教您特定主题的团队或对其进行更新 促进个人成长的最大动力之一是必须向其他人传授有关该主题的知识。 最后，加紧引导 Scrum团队没有明确的”领导者”，Scrum Master也不是团队的”领导者”。敏捷团队正在自我组织。团队通常需要朝着正确的方向努力，但是让团队成员加强并领导sprint活动的各个方面是可以的（实际上更可取）。 完美的Scrum Master不存在。但是，您猜怎么着 - 您也不完美。因此，下次您要抱怨Scrum Master时，请后退一步，尝试了解他们在Scrum Master旅程中所处的位置，并伸出援助之手，使他们继续前进。Scrum Master将受益，团队将受益，您的工作关系将得到改善。这是双赢的局面。 关于作者 德怀特-金登 这是敏捷联盟社区博客文章。所代表的观点是个人观点，仅属于作者。它们不代表敏捷联盟的观点或政策。 原文链接 作者：Dwight Kingdon 译者：Bob Jiang
2021/1/2
articleCard.readMoreBob的2020
2020最后一天，回顾一下“折腾”的一年。我是一名爱“折腾”的Scrum培训师。 数字 年度总结我们就从数字开始吧。数字是最有说服力的。 网站 - Bob Jiang博客的一年数据如下: 总体来看，点击率很低。2021年可以考虑如何提高内容质量。 微信公众号 - （敏捷家AgilePlus，粉丝数5055；HiBlock区块链社区，粉丝数7937） 知乎 - （关注418，盐值709） twitter - （粉丝678） Telegram - （Bob和他的朋友们59） Youtube - （订阅372） Bilibili - （粉丝161） 从数字来看，2020年结果很普通。没有抢眼的数字。 最主要的平台还是在微信公众号。另外需要提升的是知乎（权重高）的关注。 阅读 2020的阅读几乎都在微信读书的听书完成的。一共读了20+本书（只记住这么多，还有一些只听了一半的没有记录了。） 非暴力沟通 高绩效教练 用户故事地图 理查德费曼传 刷新 重来1，2，3 小狗钱钱1，2 断舍离 财务自由之路1，2，3 中间人经济 苏世民：我的经验与教训 无限的游戏 百万富翁的快车道 富爸爸穷爸爸 启示录 非对称风险 重构学习体验 社区运营的艺术 新家庭如何塑造人 建筑模式语言 行为设计学 掌控习惯 超级天使投资 影响力 如何说孩子才肯学 精力管理 大教堂与集市 这些书主要分3类：
2020/12/31
articleCard.readMore章鱼对敏捷组织设计的启示 | 敏捷联盟2020年十大博客
此条目是作为”支持敏捷采用”计划的一部分而编写的，该计划是一项致力于支持组织及其员工变得更加敏捷的敏捷联盟计划。 生活中有些问题根本没有好的答案。”我们为什么做梦？”，”我们独自在宇宙中吗？” 和”谁杀了吉米-霍法？” 属于此类别的另一个问题是”敏捷组织结构是什么样的？” 然而，这是我发现自己在今年12月于斯德哥尔摩举行的”支持敏捷采用”~sources~(~‘Supporting*20Agile*20Adoption))~searchTerm~’~sort~‘createdDate~sortDirection~‘desc~page~1))研讨会上与敏捷同事和同事一起思考的问题之一。（要收听研讨会中某些主题的摘要，请收听此敏捷教练网络*播客的这一集。）* 组织设计是既不是”正确”也不是”错误”的事情之一。就是这样 组织选择管理其工作的方式反映了它认为有价值的东西：组织结构包含对一种组织立场或另一种组织立场的偏见。 一些组织重视清晰度。分层结构有助于描绘命令链，并在决策制定中创造可预测性。面对棘手的情况，不知道该怎么办？只需问问您的经理，她就会告诉您接下来的步骤。如果没有，她会问她的经理，依此类推。将会得到答案；方向将给出。 当然，尽管获得了好处，但是这种组织方式也面临着许多挑战。层次结构往往会忽略思想的多样性，遇到模棱两可的情况时决策速度可能会很慢，并且无法很好地适应复杂的环境。这是敏捷组织越来越多地寻求组织工作的其他更现代替代方案的原因之一。 例如，Spotify的组织结构方法倾向于优化以创建可持续发展的团队，并专注于其产品的特定元素。正如Spotify的Marcin Floryan向我解释的那样，工作被带到了团队中，以便这群人可以在相当长的一段时间内一起工作并表现得更好。例如，一个团队可能会专注于其Podcast产品的元素，并会在一段时间内专注于该领域。当业务需求发生变化时，同一团队可能会将重点转移到产品的其他元素，例如用户的个性化播放列表或推荐。这种结构是自然产物，人们会偏见-绝非偶然。 尽管这种组织方式对于团队清晰，团队间协作和友善而言可能是很好的选择，但Marcin坦承，它也面临着挑战。当团队位于同一地点时，这种组织结构会很好地工作，但是当员工以分布式方式工作时，这种组织结构的效率就会降低。随着组织规模的扩大，分散的团队往往会成为规范，而不是例外，因此，即使在Spotify，这也不是简单的方法。随着团队时间的流逝，这种结构也会给性能带来挑战。正如Heidi Helfand在”动态再分配“中所指出的那样，团队（和组织）经历了自然的”生态循环”，实际上，中断可能是必要且健康的–使团队保持完整状态的时间过长可能会适得其反。 随着12月周末小组讨论的发展，我们同意组织结构在最大限度地提高VUCA商业环境所需的业务敏捷性方面存在固有缺陷。还有其他比喻可能更好地说明敏捷组织如何努力组织自己吗？ 在这种情况下，也许寻找自然并研究有机物可能会有所帮助。Bossa Nova的顾问兼合著者约翰-巴克（John Buck）指出，人脑在尝试学习某些东西时会释放突触前蛋白*神经毒素，*以寻找建立新突触所需的位置。发生这种情况时，没有预设的结构或途径-神经毒素化学物质随新化学物质编码一起分配，该编码指定了新学习的要求。 这个概念是一个有力的类比：随着组织拥抱变化并有目的地执行，他们不仅要按照战略意图协调员工，而且还需要在业务条件变化时快速感知，学习和响应。这类似于大脑检测到变化并对新的适应做出快速反应时发生的情况。 然而，这种类比可能会很有趣，但感觉却很”自上而下”且层次分明。顶部有一个大脑，该大脑发出要做什么的信号，身体的其余部分只是做出反应，并不自己思考。 那么，更贴切的有机类比可能是看一个柔软的八足头足纲动物-章鱼。这种软体动物具有极其复杂的神经系统。实际上，其三分之二的神经元都包含在无脊椎动物自己的触角中，因此您可能会认为章鱼有多个”大脑”。这意味着章鱼的身体部位可以做出自主决定，而无需响应自上而下的命令。章鱼也是著名的抗衰老产品。如果将手臂移开，它会立即开始重新生长过程，从内部神经束到其外部吸盘，一个非常细小的触手重新生长。谈论创意破坏！ 就像爱立信执行官和SAA计划主管Hendrik Esser在我们的研讨会上宣称的那样，这也许意味着组织”需要变得更像章鱼！” （我承认这句话，我从没想过我会在敏捷领导力研讨会上听到。） 这种类比在理论上很吸引人，但是在组织环境中应用时并没有那么简单。在实践中，”大脑”将如何协调组织中的决策？就像章鱼一样复杂，它最终是一个具有确定的静态目标的无脊椎动物-获得食物并繁殖。分散，自主的决策如何转化为需要处理更复杂问题的组织？ 那自私呢？章鱼-整个身体-具有战略意图。大脑的自我利益与触手中神经元的利益完全一致。没有一家公司可以竞争成为Octopus，Inc.的首席执行官。但是，在一个组织中，这对组织最有利，对本地市场或部门主管而言可能并不最适合，这看起来像什么？当需要协调利益冲突并以某种方式将其付诸实践时，这意味着什么？与章鱼类比一样，内容丰富且发人深省，当我们尝试在组织环境中翻译许多概念时，它很快就崩溃了。 最终，我意识到组织结构旨在创造的是*其员工之间共享的现实感*。一种及时共享信息的方式，可以在为组织创造价值的决策上进行。速度，协调和协作至关重要-您的工作环境将定义组织的外观。 因此，没有单一的”敏捷组织结构”，我们可以将其插入组织并神奇地期望敏捷会出现。没有超自然的或有机的类比-不会像彩虹一样跳跃的独角兽或光荣的海妖-会巧妙地解释敏捷组织如何管理其工作流程。 相反，正如我在”解锁敏捷性“中所解释的那样，在Jutta Eckstein和John Buck的” Bossa Nova ”中进行了阐述，并在超越预算之外的领导模型中进行了进一步定义，这些类比法启发了我们。我们在采用更敏捷的工作方式的组织中始终看到的价值观，行为规范和行为模式。 这些列表虽然并不详尽，但在成功的敏捷组织中我始终观察到以下关键特征： 考虑到客户的端到端视角：内部交接以及开发产品的人员和团队与接收产品的客户之间的距离最小。 实现共同目标的自我组织：人员，团队和组织结构有机地演化以提供客户价值。 致力于持续改进：敏捷不是您要成为的东西；这是你变得*更多*的东西。敏捷组织不断学习，明天会比昨天更好。 人们感到安全，有权做正确的事：高管和领导者致力于营造心理安全的环境；人们可以在边界内做出自主决策。 尽管那个12月周末在斯德哥尔摩举行的研讨会没有提供有关敏捷组织结构的答案，但它有助于弄清到达那里所需的工作。业务敏捷性不是目标；”拥抱变化并有目的地执行”是一项持续的工作。公司的组织设计只是成为更加敏捷的组织时要考虑的维度之一。 哦-毕竟，我确实得到了今年12月回答的那些不可能的问题之一。马丁-斯科塞斯（Martin Scorceses）出色的《爱尔兰人》生动地揭示了谁杀死了吉米-霍法（Jimmy Hoffa）。但是您必须亲自查看它才能获得答案–不会破坏自己！ 资料来源： https://en.wikipedia.org/wiki/Octopus#Nervous_system_and_senses https://blogs.scientificamerican.com/octopus-chronicles/how-octopus-arms-regenerate-with-ease/ https://www.amazon.com/Unlocking-Agility-Enterprise-Transformation-Addison-Wesley-dp-0134542843/dp/0134542843/ref=mt_paperback?_encoding=UTF8&me=&qid= https://www.amazon.com/Company-wide-Agility-Beyond-Budgeting-Sociocracy/dp/154467287X/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1577785309&sr=1-1 https://www.amazon.com/Implementing-Beyond-Budgeting-Unlocking-Performance/dp/111915247X/ref=sr_1_1?crid=C1S9Y1PA33IC&keywords=implementing+beyond+budgeting&qid=1577785340&s=books&sprefix=implemenrting+beyond+%2Cstripbooks%2C266&sr=1-1 https://www.amazon.com/Dynamic-Reteaming-Wisdom-Changing-Teams/dp/1733567216/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1577785892&sr=1-1 https://en.wikipedia.org/wiki/Neurexin https://elifesciences.org/articles/35692 原文链接 作者：Jorgen Hesselberg 译者：Bob Jiang
2020/12/31
articleCard.readMore远程会议的小窍门 | 敏捷联盟2020年十大博客
疫情开始后，许多习惯去办公室的人正在家里工作。 我本人大部分时间都待在家里，避免与同事和朋友，尤其是65岁以上或有医疗问题的同事和朋友进行面对面的交流。 这意味着更多的远程会议，远程工作会议和远程社交追赶。（我的读书俱乐部将在周日通过Zoom开会。） 我们如何才能充分利用远程会议的优势？我主张所有会议都采用轻量级的结构，但是在远程会议中，结构更为重要。 我发现这些简单的更改大大改善了远程会议。 提前发送目的和议程，然后在会议之前重新发送。目的解释了会议的原因，议程解释了到达会议的步骤。在议程的基础上，需要一个过程来帮助该小组共同思考和决策。在会议开始时检查目的和议程。对于每个议程项目，在达到这一点时都要说明其过程。在开始时说明整个会议的过程可能会使人保留太多细节。 在会议开始时，介绍您正在使用的工具-如何静音和取消静音以及其他相关操作。提供一些有关交互的准则。例如，在四人或五人以上的会议中，我要求人们静音，除非他们讲话。 考虑在会议开始时添加简短的签到。可以理解的是，许多人感到担忧和压力。签入可以使人们有空间共享他们所发生的事情，并帮助他们暂时搁置它。这也可能是预示着可能会有孩子在后台徘徊的时候。 指出您何时完成议程项目并继续进行下一步。检查以确保每个人都准备好继续前进。如果您正在观看视频，则可以要求一个肯定的信号。如果有人在音频上，请问”谁能为此做出更多贡献？” （”每个人都准备好继续前进了吗？”这个问题是不可靠的。） 尽可能使用结构化的问题和活动。如果您打算进行任何活动（如回顾活动），请选择可以单独进行的活动，除非您拥有带分组讨论室功能的视频或允许所有人参与的工具（例如，Miro）。 发送带有会议议程的会议中您将要引用的所有URL（例如google doc）。如果您打算参考数据，则即使在会议期间要使用屏幕共享，也要提前发送。当您无法控制滚动时，实时吸收数据最多是困难的，通常是不可能的。 如果您有提示和资源，请在下面的评论中发布它们，我将在以后的帖子中分享。 好好照顾好自己和周围的人。有了准确的信息和合作，我们将解决这个问题。 关于作者 埃丝特-德比 这是敏捷联盟社区博客文章。所代表的观点是个人观点，仅属于作者。它们不代表敏捷联盟的观点或政策。 原文链接 作者：Esther Derby 译者：Bob Jiang
2020/12/30
articleCard.readMore敏捷方法是过时的领导力所不及的 | 敏捷联盟2020年十大博客
敏捷是老套领导力无法比拟的。过时的领导力注重的是管理和工人的分离；如何更好的把敏捷明道理实施落地，1. 专注于集体智慧；2. 创造创新的心理和职业安全；3. KPI和奖励基于价值创造而不是利用价值
2020/12/29
articleCard.readMore超越预算角度的OKR | 敏捷联盟2020年十大博客
本文从超越预算来分析OKR（目标与关键成果），主要从三个角度来分析和质疑OKR（但并不是否定OKR）。相比国内一味的追捧OKR，这是一篇不可多得的文章。
2020/12/28
articleCard.readMoreAgile123.net上线啦 | 敏捷学习资源大全
写在前面 非常感谢 ETH123.org 的启发，在以太坊资源大全网站上线的时候，给我提供了灵感。尤其他们的网站是开源的，我可以直接 fork 下来进行改造即可。真心感谢ETH123.org，尤其还是感谢以太坊爱好者的曾汨和开发小伙伴。（帮我解决了一个技术问题） 还有哪些需要优化 目前还有几个地方有待进一步优化： 收集更多的敏捷相关学习资源 制作 Agile123.net logo 每个资源（网站）的logo收集 对于资源分类的建议 任何想法和建议，都欢迎在 github 上面提交issue。 目前有哪些资源 敏捷学习资源分类 当前的分类如下： 热门推荐、社区、敏捷框架、Scrum专区、大规模敏捷、产品设计、DevOps、敏捷度量、意见领袖、工具、资讯、博客、咨询公司、敏捷图书、敏捷实践等 收集的敏捷学习资源网站 这里就不一一列举了，如果你的博客，网站也想收录进来 欢迎在 github 上面提交issue。 最后，如果你认为这个站点对你有帮助，欢迎分享给更多的伙伴。 谢谢你的分享。
2020/12/25
articleCard.readMore培训总结 - Certified ScrumMaster 课后作业记录
CSM培训总结 为期4天的CSM培训结束，自己对敏捷有了更深的认识，scrum是一种轻量级的框架，但却有着功能强大的价值观，原则和实践，主要体现在团队能在短期内能够尽快地响应变化，交付产品，快速反馈，适应变化，连续提升，相比较使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就会降低。 在scrum 三个角色当中，我觉得SM相对来说比其他两个角色重要，SM作为team leader和PO紧密地工作在一起，可以及时地为团队成员提供帮助。他的职责在于以下五点： 保证团队资源完全可被利用并且全部是高产出的。 保证各个角色及职责的良好协作。 解决团队开发中的障碍。 做为团队和外部的接口，屏蔽外界对团队成员的干扰。 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review 和Sprite Retrospective。 SM除了主持Daily Scrum之外，还有三个主要职责： SM需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化。 SM需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的条目。 SM还必须仔细考虑进展中的任务数，进展中的工作需要得到最小化，以实现精益生产率的收益。 SM需要找出阻碍 Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。 现在的工作模式基本是按scrum来运作的，在迭代开始前，会有需求清单(Product Backlog)，PO会把Product Backlog排出优先级，识别出更有价值的需求排在靠前，团队从需求清单中选择迭代中要完成的US(Sprint Backlog)，由SM给每个成员做任务划分，然后成员根据开发的周期输出自己计划，将US拆分成每天要完成的Task，每天上班先进行Daily scrum，反馈前一天完成了哪些任务，今天要完成的内容，其中遇到的一些问题，SM通过沟通，协调资源等多种途径解决在Daily scrum中反馈的问题，Sprint Backlog完成形成Increment，由PO和用户验收，之后团队进行Sprite Retrospective，总结出急需改进的Top问题以及继续保持的点。 不过还是有些差异，比如Scrum角色中的PO，只能定位作为一个决策者，团队在迭代过程中遇到解决不了的问题以及与其他团队协作问题等，才由PO来沟通，解决；而需求条目的澄清则由团队中专门负责需求整理输出的同事来承担，这可能是由于商业合作产生的这种模式。再比如迭代的周期都比较长，一个迭代至少3周甚至更长才能完结，迭代的交付时间中固定的，团队只能通过施压的形式，来要求团队成员按照交付时间点来完成产品Increment。 – CSM学员 宋
2020/12/24
articleCard.readMoreScrum敏捷管理学习心得 - Certified ScrumMaster 课后作业记录
Scrum敏捷管理学习心得 敏捷开发是一种能应对快速变化需求的软件开发能力，包含Scrum、极限编程（XP）、晶体、特征驱动开发等多种方法。其中Scrum是最被广泛使用的一种方法，旨在指导团队进行产品的快速迭代和增量交付。 敏捷软件开发宣言： 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值观：个体的互动高于流程和工具、工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划。 敏捷宣言遵循的原则： 1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 2、欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化。 3、经常的交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。 5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 6、不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈。 7、可工作的软件是进度的首要度量标准。 8、敏捷过程倡导可持续开发。责任人、开发人员和用户能够共同维持其步调稳定延续。 9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 10、以简洁为本，它是极力减少不必要工作量的艺术。 11、最好的架构、需求和设计涌现于自组织团队。 12、团队定期地反思如何提高成效，并依此调整自身的举止表现。 敏捷的五个核心价值观：专注、公开、承诺、勇气、尊重。 Scrum的三个核心角色：Product Owner（PO）、Scrum Master（SM）、Scrum Term（团队）。 其中 PO的核心工作为：对团队对外交付的价值负责，定义需求、定义需求的优先级和验收标准、定义产品发布内容与日期。 SM的核心工作为：帮助团队遵循Scrum框架，持续改进，促进团队工作，帮助团队排除影响生产力的障碍、保护团队不受干扰。 Scrum Team则对交付结果负责，敏捷团队是自组织的团队、小而美，一般团队成员定义为5-9个人。 Scrum的3个工件：Product Backlog（产品待办列表）、Sprint Backlog（Sprint待办列表）和Increment（可交付产品增量）。 Product Backlog即产品视角的需求清单，由PO负责维护，并根据优先级进行排序，优先级高的颗粒度更细，优先级低的对应颗粒度粗。用户故事是其中一种最佳实践，每项需求都应该描述其外部价值。 Sprint Backlog即冲刺周期内规划要完成内容，来源于Product Backlog，由团队评估和选择Product Backlog中哪些放入Sprint Backlog，同时团队需要一起定义完成的标准。 Increment即冲刺结束后可对外发布的产品功能增量部分。 Scrum的5个事件：Product Backlog梳理会议、迭代计划会议、每日站会、迭代评审会、迭代回顾会： Product Backlog梳理会议贯穿整个Scrum项目的始终，主要保持产品待办列表有序、凸显价值。 迭代计划会议作为Sprint的开始，决定在迭代中完成哪些待办列表，明确任务和战前鼓舞。会议时长对应Sprint周期每周2小时。 每日站会，会议时长建议为15分钟，检视上一个工作日做了什么，当天的工作计划和存在的问题，阐述最好是可视可量化的，问题不发散，做好时间管理。 迭代评审会议：会议时长一般每周对应1小时，在sprint结束时团队和相关干系人一起评审sprint的产出、完成工作是否符合需求预期，并展示当前产品增量情况。 迭代回顾会议：会议时长一般每周对应45分钟，在sprint结束后，scrum团队开会反省和检讨，对迭代周期内做的好的进行表扬和鼓励，不好的，提出改善方案和完成计划。 Scrum敏捷开发的优势：拥有快速反应的能力，精确要求，精准结果，更大的灵活性和稳定性、提高团队绩效，降低成本，失败的代价降低。劣势：敏捷注重人员的沟通，文档维护难度增加，在新员工较多未形成战斗力时，老员工较累。 结合当前项目实际情况的分析： 1）团队人员数量超出了Scrum的最优定义，站会易超时； 2）PO是新人，没有明确的职责定义，对产品认识度不够。 3）验收标准有时候没有很明确的定义，在长期不上线使用的情况下，拉通联调的支持周期过长，容易“带病”到后面的迭代。 4）新人较多，效能提升，共同价值目标磨合需要时间沉淀。 5）对于迭代评审会议，目前做的不够，没有很好的展示迭代输出成果。 6）奖惩制度不合理，在不断的高压冲刺中，难以长期的保持团队成员的斗志和凝聚力。 相信每个SM在Scrum交付过程中，总会遇到由内到外、由外到内等各种问题，需要不断地反思、学习、总结，所有的管理问题，最终都是人的问题，唯有持之以恒的学习反省，才能走的更远。 限于时间精力和篇幅，先写这么多吧，望谅解！ CSM考试学员：徐某 2020-12-23
2020/12/23
articleCard.readMore敏捷交付 - Certified ScrumMaster 课后作业记录
敏捷交付 对于敏捷交付培训与实际运用中，我理解为我们需要持续不断的及早交付满足客户有价值的的软件，在交付过程中不断通过变化，通过及时沟通，标准的流程，统一化的工具，进行可持续，高效的交付。 在软件开发中，领导阶层的指挥控制方式（经理创建详细的工作细分结构、向团队分配任务，并告诉他们每项任务要花多长时间完成的方式）存在问题。敏捷方法从业者认识到，实际执行工作的人才是制定这些决策的最佳人选。开发人员确定他们的任务，他们执行自己的评估，他们自愿挑选任务，他们自行分担工作量。在本质上，他们就像一个高效运转、自行组建的团队，没有明确定义项目经理职位。相反，该团队指派某个人作为团队领导，帮助推进整个流程，让团队成长，让团队在缺少SM这个角色后，还能依然运转。 我从如下几点详细描述我了解的敏捷交付: 产品路线图， 项目目标与里程碑， 团队成员责任划分， 团队流程与工具管理， 项目风险管理， 团队反思。 第一，产品路线图。 在产品路线定下来以后，根据产品的背景、前景和价值，让团队意识到该项目的重要性，了解产品的主要交付路线，产品主要需求的优先级，以及大致上线时间点。 第二，项目目标与里程碑。 主要是对产品路线的补充，对交付功能模块的细化，项目完结交付的所有功能点，SM基于产品路线和需求进行模块拆解，澄清所有功能点，对总目标功能点的里程碑设定，以及每个里程碑各个职能组完成的主要任务； 第三，团队成员责任划分。 主要是基于项目功能，明确团队成员和职责，让团队对每个人所负责有概念认识，基于功能和流程，明确团队成员和职责，对项目开展的相关环节的必要说明，大家共同遵守的团队规则章程，明确团队共识的协作方式。 第四，团队流程与工具管理。 为了确保共识计划得到落地执行，团队保持高效交付，那么就需要借助一些研发管理工具，辅助我们进行项目开展实施，同时在项目交付的过程中不断优化交付流程，代码管理，需求管理，人员管理，交付件的管理，将产品需求、项目任务、测试Bug以及其他事项都及时录入到项目管理工具，持续跟进、督促、检查，争取将所有事务录入项目管理工具，包括未被考虑的事情，让团队自己给自己建任务。 第五，项目风险管理。 主要是向团队成员告知个人任务进度和安排，以及需要支持的相关事项，及时暴露风险和问题；同时交付过程中存在需求理解，表达不清晰的地方，人员理解不一样的地方，要及早暴露出来这些风险，通过与客户沟通及视补救，沟通过程流程与工具能够尽早把风险扑灭。 第六，团队反思。 团队定期的反思如何提高效率，并以此调整自己的能力，让团队没个人都能够成长，同时淘汰不符合团队的人，让团队人员更加稳定延续，人员稳定才能保证项目的稳定，让团队成员执行力强，凝聚力强，没有旁观者、推诿者，共担解决；能力强，独挡一面，人人都是神枪手。 通过这6点，我们能够提醒、督促、辅助我们落地美好计划，让团队管理更加透明，让项目实施更加具体、让项目风险更加可预期，同时也可以加速交付节奏，做到极限编程，有着稳定的工具，流程，人员，并以即时的方式来让项目投资获得最高回报。 – CSM 学员陈某
2020/12/23
articleCard.readMoreGithub指定本地私钥访问仓库
一共有三个关键步骤： 生成新的私钥 上传公钥到github 修改本地ssh配置 Mac pro迁移后，本地的 github 私钥忘记是哪个，重新生成一个新的私钥放在一个新目录。（怕覆盖了原来的私钥，其他应用受影响） 1. 生成新的私钥 ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/Users/<default>/.ssh/id_rsa): <your new path>/id_rsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in <your new path>/id_rsa. Your public key has been saved in <your new path>/id_rsa.pub. The key fingerprint is: ... ... 注意指定一个新的目录 <your new path>
2020/12/21
articleCard.readMoreGitcoin第八轮支持活动（如何申请资金支持）
Gitcoin第八轮支持活动 原文链接 发表于 2020年11月26日SCOTT MOORE 以下内容为机器翻译，准确信息已上述的原文链接为主。本活动是Gitcoin组织，解释权归Gitcoin。 从12月2日至12月17日，获得50万美元的集合资金，立即创建您的赠款 今天，我们很高兴宣布最新一轮的Gitcoin Grants。在过去的七轮中，在您的支持下，我们已经为超过700个关键的以太坊生态系统项目分配了超过3百万美元的资金。它不仅取得了巨大的回报，看关键 成员 的 我们的 社区获得可持续的资金来源，它是惊人的测试二次资金作为一种机制来满足我们不断增长和维持3D人类是建立我们依靠开源软件的更广泛的使命（OG Internet创建者有很多方式）。 但是，与以太坊生态系统一起工作有一些独特之处。如果我们不得不尝试提炼它，那就是社区总是团结在一起。我们将彼此之间的关系视为连续的，无限的游戏，并将与其他创作者的所有工作视为正和。我们发现，这不仅在补助金中而且在与社区的许多其他互动中都是如此。以太坊擅长建立小队财富。 正是这种认识使我们决定在Gitcoin Grants第8轮中尝试一些独特的事情（毕竟这是一个幸运的数字）。使人们团结在一起，共同学习并维护公共物品。 因此，我们很高兴宣布Gitcoin Grants Round 8（GR8）Hackathon，以及我们最大的配对资金池，其中有超过50万美元来自我们的新资助者联盟资助的6个类别。我们希望随着牛市的回归，我们可以使开源创作者获得最高100万美元的资金，并吸引更多的二次自由职业者。 如果您有兴趣参加此活动，则需要以下所有链接： 创建一个Grant。您要在Web 3中进行构建吗？您的工作很有价值。资助+加入社区！ 注册到Hack：使用1inch，Balancer，Ceramic，Gnosis，Keep，Panvala，Nexus Mutual和其他10个版本进行构建 加入我们（虚拟）庆祝Web 3。在2周内始终开放的GR8 Airmeet中进行20多次活动 如果您不确定要做什么，或者只是想与我们discord，请加入Gitcoin的全新Discord，在此回合中，受赠者，贡献者和黑客将在这里闲逛！ 那么，Gitcoin Grants如何运作？ 它从”赠款”页面，资金池和贡献者社区开始 赠款从您的项目页面（或您自己！）开始，以及一组匹配的资金。借助二次资助的力量，捐助者将表明他们对受赠者的支持，并民主地决定匹配资金的去向。 如果您是受赠人，则需要注意的关键是，对项目的每笔捐款的*数量*和*金额*都会影响分配给您的总额。如果您是贡献者，那么即使是很小的贡献也会对受赠者获得的对等资助金额产生巨大影响。 换句话说，Gitcoin Grants实际上就是社区共同努力，以帮助为公共物品提供资金和表示支持。而且我们都受益于公共物品。 前往https://wtfisqf.com/?grant=1,1,1,1&grant=4&match=1000来体验QF的基本功能！ 第七轮回顾 第七回合的配对资金为45万美元（较上一轮增加150％），这主要要归功于DeFi的所有人（甚至是匿名人士）。主要资助者包括以太坊基金会（我们的第一个主要支持者<3），optimism（另一个长期支持者），yearn（在第七轮成功的许多方面的催化剂），balancer，Synthetix，Chainlink，threearrowscap等。 我们还看到了近200个新项目参与，使总数达到850个以上。在产品方面，我们将工作重点放在了更好的Sybil抗性，更快的（和更便宜的）第2层结帐交易以及集合上！ 在第7轮中，社区支持的新水平对我们而言是一个重要的里程碑，也是朝着实现二次自由职业的愿景迈出的非常谦卑而重要的一步。如果您想了解更多信息，请在此处查看Vitalik的Round 7回顾展。 第8轮–有什么新功能？ 除了修正总体贡献者和受让人的体验之外，我们还指导了以下几项工作： 多个CLR；多种资金 作为资助者，您可以捐赠到多个类别或收藏集。作为受赠者，您可以轻松参与多个匹配池！ 您的资助页面 我们希望获得一个赠款页面，该页面中的描述中要包含清晰的”要求”，因此，作为Gitcoin，我们可以在GR8黑客马拉松期间与我们的社区联系，以解决特定问题。在此处阅读更多一些技巧，以最大限度地提高您的匹配度。 赠款页面现在显示了更美的爱墙 现在可以选择将视频简介上传到您的资助说明中 向Sybil抵抗前进（一次整合！） 除了SMS，BrightID和Twitter，我们现在还集成了Idena，POAP和Gmail，以验证您是否是贡献者，以增加您为之贡献的赠款的匹配金额。 受赠者通过Twitter进行自我验证，而贡献者通过各种选择以增加其信任奖金的方式进行自我验证。 活动阵容！ GR8黑客马拉松 第一个旗舰Gitcoin授予Hackathon！此次联合活动不仅有机会召集社区，不仅围绕他们关心的资金项目，而且也有助于建立社区，请在此处阅读更多内容。
2020/12/1
articleCard.readMoreScrum指南最新版 2020 Scrum权威指南 游戏规则
Scrum 官方权威指南 收听有声版 | 官网下载PDF 由Scrum创始人 Ken Schwaber 和 Jeff Sutherland 开发并维护 版本：2020中文版 | 查看旧版本（2017） Scrum 指南的目的 在 1990 年代初，我们开发了 Scrum。在 2010 年，我们撰写首版 Scrum 指南，以帮助全世界的人们理解 Scrum。自那时起，我们通过小的功能更新对 Scrum 指南进行了演进。我们是 Scrum 指南的共同后盾。 Scrum 指南包含了 Scrum 的定义。框架的每个元素都有其特定的目的，这对于使用 Scrum 实现全部价值和成果是至关重要的。如果更改 Scrum 的核心设计或理念、遗漏元素或不遵循 Scrum 的规则，将掩盖问题并限制 Scrum 的好处，甚至可能变得毫无用途。 我们关注到 Scrum 在日益复杂的世界中应用越来越广泛。我们很荣幸地看到 Scrum 在许多本质上具有复杂性的工作领域中被采用，超越了 Scrum 的起源领域——软件产品开发。随着 Scrum 的应用范围不断扩大，developers、研究人员、分析师、科学家和其他专家都能在工作中应用。因此，我们在 Scrum 中使用 “developers” 一词并不是为了排除其他使用者，而是为了简化统称。如果您从 Scrum 中获得价值，那么您可以将自己视为其中一员。 在使用 Scrum 时，可能可以找到、应用和设计适合本文中所描述的 Scrum 框架的模式、过程和见解。它们的描述超出了 Scrum 指南的目的，因为它们因 Scrum 的使用具体情境不同而不同。这些使用 Scrum 框架的特定技巧有很大的差异，因此不在本文中描述。 Ken Schwaber & Jeff Sutherland 2020 年 11 月
2020/11/12
articleCard.readMore敏捷之旅中国 2020 汇总
敏捷之旅介绍 Agiletour（以下称为敏捷之旅）是一个国际非盈利性组织，于2008年成立，总部位于法国，由帕特里斯·佩蒂特发起。其目的是提供一个高效有趣的敏捷开发学习途径，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。 2020 各地敏捷之旅时间 11.22 北京敏捷之旅 11.28 郑州敏捷之旅 11.29 长春敏捷之旅 11.29 深圳敏捷之旅 12.5 大连敏捷之旅 12.6 沈阳敏捷之旅 12.13 上海敏捷之旅 [12.13 天津敏捷之旅]() [12.27 广州敏捷之旅]() 英文官方网站 敏捷之旅英文官方网站 招募 如果你想为敏捷在中国的推广贡献自己的力量，可以联系 bob@bobjiang.com 如果你想举办所在城市的敏捷之旅，欢迎在下面的issue留言。 - 申请举办敏捷之旅2020 提交举办信息（已经确定举办，尚未列在上面） - 申请举办敏捷之旅2020 目标 敏捷之旅的主要目标是： 大量交流敏捷 我们的主要任务是在整个十月和十二月的几个月里，以我们的行为进行一次“大众交流”。我们希望在有受众的任何地方进行交流，以吸引更多对我们新的专业方法的关注 分享我们对敏捷的看法 由于敏捷不断发展，我们希望向新视野开放，同时也为敏捷社区贡献我们的理解，解释和想法 联邦制 鼓励世界各地在敏捷领域中发挥领导作用，同时与敏捷文化和自我组织保持一致 支持 协助我们的同事和当地企业采用敏捷 总而言之，AgileTour敏捷之旅的任务是突出世界各地的领导组织并创建敏捷领导者，并协助大众传播敏捷的好处及其对世界专业人士的影响。因此，AgileTour敏捷之旅旨在帮助所有的组织和企业，这些组织和企业将以敏捷方法论为基础和使命。 以往活动的总结
2020/11/8
articleCard.readMoreScrum指南最新变化 2020版本
Scrum指南 更少的规范性 多年以来，《Scrum指南》变得更具规范性（Prescriptive）。2020版旨在通过删除或软化说明性语言，将其恢复为最低限度的框架。 例如： 删除了每日Scrum问题， 软化了围绕PBI属性的语言， 软化了Sprint待办事项围绕回顾会的语言的条目 缩短了取消Sprint的部分等。 一个团队专注于一个产品 一个团队专注于一个产品的目的是消除团队内独立团队的概念，这会导致产品负责人（PO）和开发团队之间的“代理”或“我们和他们“的行为。现在只有一个Scrum团队专注于同一个团队目标，具有三组不同的职责：PO，SM和开发人员。 产品目标的介绍 2020版的《Scrum指南》引入了产品目标的概念，为Scrum团队向更大的有价值的目标迈进提供了重点。每个Sprint都应使产品更接近整体产品目标。 冲刺目标，完成的定义和产品目标的目录 之前的《Scrum指南》描述了Sprint目标和完成的定义，但并没有真正给它们提供身份。它们不完全是工件，而是有些附属于工件。除了2020版对产品目标提供了更清晰的说明。现在，每个工件中都包含对它们的“承诺”。 对于产品待办事项列表（Product Backlog），是产品目标； Sprint待办事项列表（Sprint Backlog）则有Sprint目标， 增量（Increment）则有完成的定义（现在不带引号）。 它们的存在是为了带来透明并专注于每个工件的进度。 自我管理超越自我组织 self-managing over self-orgainzing 之前的《Scrum指南》将开发团队称为自组织，团队选择和谁一起工作以及如何完成工作。 2020版本则更着重于Scrum团队，强调了自我管理的Scrum团队，团队选择和谁一起工作、如何做以及做什么。 三个Sprint计划的主题 除了“什么”和“如何”的Sprint计划主题外，2020的《Scrum指南》还强调了第三个主题“为什么”，指的是冲刺目标（Sprint Goal）。 全面简化语言，扩大受众范围 2020版本的《Scrum指南》着重于消除冗余和复杂的陈述，以及消除了余下的对IT工作的任何推断（例如测试，系统，设计，需求等）。现在，《 Scrum指南》不到13页。 加入社区？ 加入社区参与讨论？ 欢迎报名我的线上课程 - Scrum敏捷精髓
2020/11/3
articleCard.readMore用户故事和任务 | 敏捷小知识 | 敏捷家出品
定义 什么是用户故事 用户故事是一种敏捷的实践，帮助开发团队从写需求的视角切换到与客户交谈需求的视角。敏捷用户故事中会有1-2句话简要描述需求，更重要的是基于这几句话的一系列交谈。 用户故事是从最终用户（或客户）的视角出发，对于他们有价值的特性的简单描述。通常是如下的格式： 作为 <某类用户>， 我想要<达成某个目标> 由于 <某个原因> 什么是任务 a: a usually assigned piece of work often to be finished within a certain time b: something hard or unpleasant that has to be done 任务的定义，来自于 韦氏词典 任务，通常是一定时间内要完成的、已分配的工作 任务，必须要做的，较困难的（令人不愉快的）的事情 这里的任务是通用的定义，在敏捷工作环境中，任务指的是团队为了完成用户故事而拆分更加细粒度的、功能模块的工作。 用户故事和任务的相同点 用户故事和任务都是开发团队必须参与的 用户故事和任务都是为了完成特性（feature）和产品的 用户故事和任务，通常都是较难的、必须完成的工作 用户故事和任务，通常都有截止日期（时间）的要求 用户故事和任务的不同点 用户故事就像裤子，而任务就像内裤 用户故事通常是解释特性的why，而任务通常是实现特性的how 用户故事是面向用户（或客户）的，而任务是面向团队的 用户故事通常是产品负责人（或客户）关注的，而任务通常是开发团队关注的 （注：开发团队也需要关注用户故事） 用户故事通常是以用户的语言进行描述（通俗易懂），而任务通常偏向于技术语言描述（如用python实现某个算法） 社区的回复 需求的价值版本描述和需求的BA-编程行为拆解？ – 悟空 用户故事用户能听懂，可以参与。任务是团队自己能理解的功能做拆解。用户故事可以是一个mvp，任务可能只是故事的一个部分，不完整。 – Bruce Wang 任务是用户故事拆分后的子项，有指定的执行者 – 嘿，愉快的人儿啊 用户故事是需求点描述。任务是拆分出来的，用以实现用户故事的条目，任务指导开发团队实施具体的工作。– Fiona W.
2020/10/13
articleCard.readMore敏捷教练课程安排计划
敏捷公开课 如果下面的课程计划中没有找到合适的时间和地点，还可以填写表格（表达课程兴趣，足够的人数即可单独联络开课） CSM 课程计划 成都 2020年10月31日 - 11月01日 | 我要报名 线上 2020年11月07日 - 11月08日 线上 2020年11月14日 - 11月15日 | 我要报名 深圳 2020年12月05日 - 12月06日 | 我要报名 CSPO 课程计划 敏捷教练训练营 上海 2020年12月17日 - 12月20日 课程介绍 CSM课程 敏捷教练训练营
2020/10/10
articleCard.readMore敏捷教练训练营2020
为什么要办敏捷教练训练营 自从2016年我开始讲CSM课程以来，总会有学员问拿到CSM证书以后可以做什么，后面如何晋级？ 其实证书本身有什么用呢，这个是值得打个问号的。 虽然证书不代表任何内容，证书也不一定有用。但是获得证书的过程，以及共同学习的同学这是一笔很好的回报。 在获得证书的过程中，可以了解到自己的知识有哪些欠缺的地方，可以梳理出知识结构，还可以学习到正宗的Scrum知识。 不论你是否持有CSM证书、PMI-ACP证书或者其他敏捷证书，是否有想过下一步该往哪里去呢？ 敏捷教练训练营就是为了给这样的实践者，提供一个晋级的可能性，晋级的可能方向。 在今年（2020）早些时候，我找到Lucy和Lance两位大神，协商我们是否可以一起开发一个课程。目的是为了提高敏捷教练的能力，从而可以让他们能更好的服务于组织和公司。（最初的目的是为了现有的CSP服务，实际上我们不想限制于这个群体，只要是有经验的敏捷教练，都欢迎来参加。） 欢迎各位CSM,CSPO,CSP,PMI-ACP,DOP等等证书持有者，也欢迎各位实践者参与到我们的训练营中来。 敏捷教练训练营包含什么 这个训练营中包含什么内容？ 以自我认知和自我成长为基础，重点提升讲授（Teaching）、辅导（Mentoring）、教练（Coaching）、引导（Facilitating）能力。 我要报名 想要了解更多信息
2020/9/11
articleCard.readMoreCertified ScrumMaster (CSM) 培训学员总结 - 辛光烁
作者：辛光烁 在艾威的课程班报名了scrum master的培训课程后，我花了一段时间认真的重新将老师的网络课程以及scrum指南回顾学习了一次，以下是我对scrum master的一些感受。 我个人是从事传统汽车行业的，对于传统的汽车开发/甚至是传统的汽车软件开发模式，一般遵循的是瀑布模型，从分析，设计，开发，测试，所有阶段是分开的，当我们结束分析后再去进行设计，设计做好后在做开发，等等。这种模式属于传统和经典模式，在汽车行业中至今仍然在使用。一些车载软件的娱乐系统更新换代的周期在几年以上，在长周期背景下，将每一步做好也可以节省成本。 但是在软件开发中我意识到，如果开发软件的同时也有大量的需求的更改，那么存在两周情况，意识退回去重做，造成延误，二是不能响应市场的需求，这两者在基于互联网开发的背景下是致命缺陷。版本迭代周期过长，没有办法满足用户需求上的变化。于是我想学习一下敏捷开发是如何解决问题的。 通过学习，我自己的认识是，在敏捷中为了解决需求的变化，可以将分析，设计，开发和测试通过不同用户故事的条件下组成不同的开发周期，组成不同的条目，如果要增加需求，那么只需要增加相应的用户条目，由PO进行确认并排序优先级，或者相反的删除需求，对于整体项目的损耗就降低了很多。同时在开发的同时，也有机会对趋势重新进行分析，这样开发的产品永远都可以跟上市场的节奏，可以实现敏捷开发。 在多种敏捷开发的模式中，Scrum是一种敏捷开发的方式，它的特点是：灵活性、适应需求变化、更适合团队比较小的情况、每一个迭代均有产出、容易学习。 对于scrum的使用流程，在每一个Scrum开始的时候，需要进行sprint计划会，确定这个Sprint要做的事产品待办列表，随后大家开始执行。在每天开始时，进行每日站会。在这一个周期结束的时候，一般是2-4周后，开sprint审查会议，审查会议之后要开一个回顾会议.以上步骤完成后，再开始下一次的Sprint。 对于scrum中的角色分类，核心团队包括产品负责人、Scrum教练和开发团队。猪队中，最重要的角色就是产品负责人，因为这个项目失败的话，他和开发团队是需要承担责任的。Scrum教练不对项目里面的任何细节负责，他只对这个团队是否合理的使用Scrum负责。 对于scrum的框架，包括产品待办列表，要不断的把已知的所有需求记录到这里面来，sprint计划会是对这个Sprint进行规划的会议。它的主要的目标就是从产品待办列表里面选择一些任务，放到Sprint待办列表中。Daily Scrum是一个用于同步进度的会议。会议形式是每日站会来进行昨天做事情，今天做的事情以及遇到挑战的总结。Sprint审查会是一个用于Sprint总结的会议。会议形式会演示产品增量，目的是把之前做的Sprint新功能给大家进行演示。Sprint 回顾会是一个用于Sprint回顾的会议。会议目的是回顾组内成员在项目开发过程中做的怎么样。 但同时，在使用scrum的过程中也需要一些注意的方面，包括Scrum绝对不能代替传统软件开发方法，Scrum适合十人左右的团队，Scrum的一个Sprint时间为2周–4周，Scrum需要一个强有力的团队等等。虽然scrum可以实现敏捷开发，但针对传统汽车行业的项目也要确定是否团队适合Scrum应用，外界的需求变化是否会很多多，这是决定使用Scrum的出发点。如果决定了使用scrum，在确定团队，相应的scrum master，找到合适的工具，比如每日看板。 欢迎报名我的线上课程 - Scrum敏捷精髓
2020/8/13
articleCard.readMore超越指责（Beyond Blaming） -- 一致性沟通
超越指责（Beyond Blaming） ©1996年 Jean McLendon 和 Gerald M.Weinberg ，www.satir.org和www.geraldmweinberg.com 英格兰虽然目前处于非常繁荣的状态，但仍表现出民族衰败的一些症状。向英国人提出任何原则或任何手段，无论多么令人钦佩，您都会发现，英国人的全部努力都是针对于发现困难，缺陷或不可能的地方。如果您对他说剥土豆的机器，他会说这是不可能的。如果在他眼前将马铃薯剥皮，他会宣布马铃薯无用，因为它不会切成菠萝。将相同的原理或同一台机器展示给美国人或我们的一个殖民者，您会发现他的脑海全是在寻找该原理的一些新应用，以及对该仪器的一些新用途。” – 查尔斯-巴贝奇（Charles Babbage），1852年 早在1852年，查尔斯-巴贝奇（Charles Babbage）就能看到衰败的症状，并从中推断出未来的表现。通过这样做，他完美地描述了指责的沟通风格，这种风格出现在”衰败”的组织中，无论是国家还是软件工程组织。什么是”指责的沟通方式”？为什么在系统开发中如此重要？【指责的沟通方式，也严重影响着家庭关系】 什么是一致性？ 一致性是一个概念，它描述了内部和外部之间协调一致的人类体验 – 思想和感觉（内部），所说的话及如何说（外部）。 为了在世界上实现一致性的运作，您需要考虑三个普遍因素：自我（内部世界），他人（直接外部世界）和上下文（事物、结构、过程、法律和文化，更大的外部世界）。 自我：您必须考虑自己的需求和能力。假设您是一位不信任任何人的判断的经理，因此您尝试参加每次技术会议。这样做可能会使您的所有可用时间都超负荷，从而无法执行管理工作，或者在任何情况下都无法做出真正的技术贡献。（或者如果你是一位不信任儿子的父母，每次和儿子沟通的时候都是持有怀疑否定的心态，那么沟通就会非常吃力。） 他人：您必须考虑其他人的需求和能力。例如，如果您是一位程序员，编写可读代码的时候拒绝打扰，那么对代码的测试和维护将是一个巨大的负担，因为这是不可能。 上下文： 您必须考虑操作环境的实际情况。 例如，如果您是一位经理，坚持使用不再具有处理任务能力的旧设计，那么不管每个人的工作多么辛苦，您的项目都可能注定要失败。 或者，如果您是一家初创公司的经理，并且花了很多钱，好像该公司拥有10亿美元的现金余额，那么您的组织可能在软件产品投入市场之前就已经倒闭了。 一致性是最基本的诚信，因此对项目及其中的每个人都具有巨大的价值。没有诚信，我们就无法建立信任。没有信任，我们不会感到安全；没有安全，我们很难做到一致性。因此，一致性可以在一个强大的增强回路中强化一致性，从而提高按时、在预算范围内构建高质量产品的机会。 相反地，同一循环会导致不一致，从而加剧不一致。如果一个项目被允许走下坡路，信息的完整性（integrity）就会被破坏。很快，人们都不可能知道真正发生了什么。这样的项目总是失败的，而当它们失败时，总是发现它们保存着两套”书”（这里的“书”指的是信息）。他们的外部形象与他们的内部形象不一致，所以项目死了。更糟糕的是，可能永远活着 – 活死人（the living dead）。 如果一致性对于项目成功是如此重要，那么为什么不是所有项目都一致呢？原因之一是一致性是有代价的。另一个是，一致性通常会带来风险。风险的水平在某种程度上取决于所显示的一致性程度（心理或情感）。 精神上的一致 在美国，相对容易地表达我们的思想而无需过多地承担责任 – 言论自由是该国赖以建立的基础。即使这样，”大声说出来”也可能要付出代价。例如，与同事或当权者在错误的时间发生分歧，可以使我们迅速走上隔离、谴责、减少机会和微妙的关门之路。因此，我们都知道了对在哪里和对谁说的话要小心的重要性。说错话会引起激烈的辩论，然后是关于谁对谁错以及谁好谁坏的声明。到那时，我们已经基本失去了增进理解和有效沟通的可能性。 情感上的一致性 在我们的文化中，情感主要用于体育赛事、庆祝活动、葬礼、临近死亡的经历，深刻感受的精神体验主要体现于战斗以及与亲密的他人之间的交流（可能是小孩或老人）。我们甚至对自己的感觉也会有很多感觉（感觉的感觉），其中最强烈的感觉与羞辱和尴尬有关。感觉是个人的，并且贴近我们的内心，在那里我们温柔而脆弱。难怪我们所有人都变得如此娴熟地否认自己的感情，这必然使我们不一致。 假设您是一个开发人员，害怕您无法兑现承诺，从而无法交付产品。您试图告诉您的经理您的恐惧，但是他毫不犹豫地告诉您，如果您不表现出更多的信心会怎样。”你为什么这么消极？你不是团队的一员吗？” 保护自己免受此类负面反应的一种方法是生活在自己的头脑中。也许您会说：”这只是一个估算；我不同意它，”这意味着您不会受到伤害，因为您已经与自己保持足够的距离，可以抵御可能暗示拒绝的任何事物。但是，尽管您否认对经理的恐惧感，但还是感觉到了，被压扁了。您可以背弃自己的想法，但始终保持自己的立场。而且，当然您一直是不一致的。 当您分享自己的感受时，您的内心被暴露在外在世界中 – 暴露在其他元素中。当您害怕并表达恐惧，同时又要考虑他人（您的经理）和上下文（项目）时，您就变得与众不同。您在这里遇到的关键问题是：”我可以分享自己的想法并且仍然可以控制吗？” 如果您的项目环境受到指责，那么如果您说实话，就有可能取消您的控制权 – 因此，对您的想法撒谎的诱惑会增加。这就是为什么责怪文化会导致”双重后果”，也就是导致失败的原因。 什么是指责？ 在一致性的组织中，您的经理问：”您的项目进展怎么样？” 您会回答：”恐怕我不会按时完成了。” 这开始了一个解决问题的讨论，你们两个都在其中制定了新的计划，以使项目重回正轨。但是，在指责的组织中，您的经理可能会告诉您，只有劣等人缺乏信心。在这种情况下，解决问题将被避免指责所取代。 从作者的角度来看，一致性的交互作用不是很大。人们只是明智地采取行动，互相体贴，完成工作并享受所做的事情。这种行为可能不如肥皂剧一般的场面，您的经理发脾气而你在角落里哭泣，但这绝对是一个好的项目。 并不是说指责文化会以一种戏剧性的，指责的方式进行每一次互动。在通常情况下，应遵循一致性的应对方法，但如果情况总是很普遍，我们就不需要管理人员。当自尊心低落时，它们会以更加明显的、不协调的典型应对方式表现出来：指责，安抚，过分合理的爱或恨，无所作为。我们不能在简短的文章中解决所有这些问题，因此让我们讨论指责，也许是应对方式中最常见、最直接的破坏方式。 在压力下，人们往往会失去平衡，这三个基本要素可能会被忽略，从而导致一种典型的不一致的应对方式。例如，当人们不考虑他人时，他们就会陷入指责状态。这是您在软件组织中可能会看到的典型的指责行为（斜体字会以这种说话方式强调 – 因为句子中的多个强调字是指责的语言符号）： 经理，因为程序员迟到了一次会议：”您*总是*迟到。您*永远不会*对*他人*表示*任何*考虑。” 为什么这不一致呢？如果经理真的感觉到并认为程序员总是迟到并且不考虑周到，那么她是否就这么同意呢？是的，但这不是这位经理所说的。她没有说：”给我的印象是你总是迟到我的会议。” 取而代之的是，她把迟到的感觉说成是科学事实，从不提供程序员可能会有不同印象的可能性。她在会议中总结了经验，就好像这些经验必定适用于所有会议一样，从来没有考虑过她的经验可能不是唯一重要的经验。 如果经理真的感觉到并认为程序员总是迟到并且考虑不周全，她可能会说：”我认为您总是迟到，而且我觉得您没有考虑过我和其他人。这也是你的看法吗？” （并省略强调的单词。）甚至更好的管理风格是使程序员有机会在进行解释之前提供不同的看法。至少，这可以防止在以下情况下的尴尬： 经理，因为程序员迟到了一次会议：”在我看来，您总是很晚。这也是你的看法吗？” 程序员：”是的，我对此感到难过。我总是迟到的原因是，我必须为死于白血病的9岁儿子献血，而他们唯一的一次捐赠就是在这次会议之前。” 经理：”对你儿子感到抱歉。我不知道 让我们找出一个新的会议时间表，这样您就不必迟到了。” 更笼统地说，它考虑到除了该经理之外，还有其他考虑因素。例如，程序员可能有来自与客户的会议，即与经理会议重叠的定期安排的会议。 但是，如果程序员真的总是迟到而又没有合理的解释怎么办？经理不是有权指责程序员吗？并非如此，因为这种情况与权利无关，而与完成项目有关。为此，使用非指责的对抗与不可接受行为有关的事实，可以最有效地解决该问题。通过前述的指责，管理者使沟通保持清晰和开放，从而最大程度地提高了程序员接收预期消息的机会。而且，收到预期的消息会最大程度地解决问题（尽管不能保证）。
2020/8/9
articleCard.readMore敏捷漫画 011
团队的问题 团队进展得怎么样？ 实际上并不太好；团队遇到了不少问题。比如…… 比如冲刺计划（sprint planning）之前梳理工作；冲刺评审（sprint review）的时候获得有用的客户反馈；团队都同意一个有意义的DoD（完成的定义）【这些问题的原因是什么呢？】 因为现在是新冠疫情，我们都是在远程工作…… 作者评论 不要认为你的团队目前像世界上大多数人一样远程办公为借口，认为保持团队合作是平淡无奇的。在这种没人能见面的时代，保持并进一步发展敏捷团队的团队精神比以往任何时候都更为重要。有了合适的在线工具，例如Miro，Zoom，Slack，Teams，Skype或其他工具，这变得可能了。但是，拥有正确的在线工具仅是答案的一半。练习“远程的团结”是另一半。 实现此目的的方法包括：在工作时间内不断开放所有团队成员的交流渠道，以模拟他们坐在一起；安排频繁的虚拟游戏会议以增强团队合作精神并一起玩乐；以及与特定同事计划在线聊天，以保持这些宝贵的临时讨论和交流机会。因此，如果您是Scrum Master或敏捷教练，现在是时候真正踏上第一步，因此即使在这些困难时期，您也可以帮助您的团队成长。 译者评论 疫情大前提下，团队合作变得更难。原来是远程团队还好，原来在办公室的团队，大家都不得不进行远程协作。这对于传统行业更为挑战。所以选择一个（套）好的工具是大前提，其次需要更多的设计团队沟通环节。因为原来团队合作，很多是发生在办公室，潜移默化（悄悄）的。而现在的团队合作，需要提前设计好固定的沟通时间、固定的沟通方式、固定的沟通渠道等等。 最后问一句，你的团队还好吗？ 读者评论 对于今天的漫画，你有什么想说的呢？ 原文链接
2020/8/8
articleCard.readMore谷歌OKR指南：如何使用OKR制定目标（含OKR模板）
获取OKR模板 介绍 研究表明对目标做出承诺有助于提高员工绩效。更具体地说，研究显示设置具有挑战性的、具体的目标能进一步加强员工实现目标的参与度。谷歌常常使用“目标和关键结果”(OKRs)来制定令人鼓舞的目标并跟踪进展。 OKRs概述 目标是鼓舞人心的并且可能会让人感到有点不舒服 关键结果是可衡量的，易于用数字记分（谷歌使用0-1.0分的数值范围） OKRs是公开的，这样组织内的每个人都能看到别人在做什么 OKRs分值的 “最佳点”是60% - 70%；如果一个人一直都能完全实现目标，那么他的OKRs就不够鼓舞人心，他需要考虑一个更大的目标 较低的分数应该被视为有助于改进下一个OKRs的数据 OKRs不等于员工评估 OKRs不是一个共享的待办事项清单 实践过程中，应用OKRs和其它目标制定技术有所不同，因为OKRs旨在制定令人鼓舞的目标。使用这种方式时，OKRs可以让团队专注于大赌注，完成比团队认为可能的更多的任务，即使他们没有完全达到既定的目标。OKRs帮助团队和个人走出他们的舒适圈，对工作优先排序，从成功和失败中学习。 学习（删减的）OKRs历史 正如英特尔前首席执行官Andy Grove（安迪格鲁夫）在他的书《高产出管理》(High Output Management)中所解释的那样，要想成功建立像OKRs这样的共享目标体系，需要回答两个问题： 我想去哪？这个答案提供了目标。 如果我要到那里（目标）的话，我该如何调整自己的节奏？这个答案提供了里程碑，或关键结果。 谷歌早期的投资者，现在的董事会成员John Doerr在英特尔时从Andy Grove那里了解了OKRs。Doerr说他加入英特尔时，公司正在从一家存储器公司向一家微处理器公司转型，Grove和管理团队需要一个方法帮助员工专注于一系列优先（重要的）事项，以便顺利转型。OKRs帮助他们沟通优先事项，保持对齐，并实现转变。 几十年后的2000年初，Doerr向谷歌的领导层介绍了OKRs，后者（谷歌的领导层）看到了它（OKRs）的价值，并在接下来的几个季度里开始进行尝试。现在，谷歌制定年度和季度的OKRs，并且在每季度召开全公司会议来分享OKRs以及对OKRs打分。 OKRs的应用远不止于硅谷，而是各种各样的组织都在应用。《财富》100强企业西尔斯控股公司向2万名员工推行了OKRs，看到其对销售业绩和个人业绩产生了积极影响。 OKRs和拉伸目标 谷歌经常会制定一些看似不可能的目标，有时称为“拉伸目标”。制定无法实现的目标是很棘手的，因为这可能被视为组建一个失败的团队。然而，这些目标往往能吸引最优秀的人才，创造最令人兴奋的工作环境。此外，当目标高远时，即使失败了目标也能带来实质性的进步。 关键是清楚地传达拉伸目标的本质以及什么是成功的门槛。谷歌喜欢制定OKRs的成功是达到70%的目标，而完全达到这些目标则被认为是非凡的表现。 这样的拉伸目标是实现长期卓越成就的基石，也是“登月计划”。 将OKRs引入你的组织 OKRs的一个重要部分是透明度。把OKRs引入到一个组织中时，弄清楚它们是什么，为什么会有用，以及将如何使用才会有帮助。研究表明当人们对他们的目标做出承诺时，绩效会更高，因此让所有人都参与进来是很重要的。 介绍OKRs的小贴士： 什么是OKRs？覆盖什么是OKRs以及它们是如何工作的基本知识。 为什么使用OKRs？回顾组织现在制定目标的方式，以及这种方式的限制和问题。 OKRs如何工作？解释时间线，对每个人的期望，主要的里程碑，以及人们将如何负责。 仍对OKRs存疑？留出提问的时间，特别要强调要提出任何的疑问。 一致性。 一旦组织知道了它关注的是什么，如何衡量成功，个人就更容易将他的项目和组织目标关联在一起。 原则&优先级。 对公司里的任何一个人或团队来说，要对一个好的想法，一个有价值的项目或一个必要的改进说“不”是很难的。一旦所有人都对最重要的目标是什么达成一致，对不那么重要的目标说不就简单多了。说“不”不是一场政治或情感上的辩论，而是对整个组织已经做出的承诺的一种理性回应。 沟通。 OKRs应当在组织内部公开，这样每个员工都知道组织目标以及成功的度量标准。一次采访中，前谷歌人、前推特首席执行官Dick Constolo被问到“你从谷歌学到了什么并应用在推特上”时，他这么说： “我在谷歌看到的，确定也应用到推特上的是OKRs-目标和关键结果。OKRs是一种很好的方法，它可以帮助公司里的每个人了解什么是最重要的以及如何衡量什么是最重要的。从本质上讲，OKRs是一种很棒的沟通战略和衡量战略的好方法。这是我们使用OKRs的方法。公司成长的时候，最困难的事情就是沟通。沟通是非常困难的。OKRs是确保每个人都了解你将如何衡量成功和战略的好方法。” 制定目标和设定关键结果 制定目标时，谷歌经常从组织级OKRs开始，用3~5个目标和每个目标的三个关键结果来对齐优先级。成功的OKRs常常是由自上而下和自下而上的建议相结合，这让组织中的每个人都可以表达他们认为值得花时间去做的事情，以及怎样最好地安排他们的时间。 制定目标的小贴士： 只选3~5个目标–过多的目标会导致团队过度扩张（over-extended）和精力分散。 避免使用那些与追求新成就无关的表达，例如“继续招聘”，“保持市场地位”，“持续做X” 使用描绘终点和状态的表达，例如“攀登这座山”，“吃5个派”，“交付特性Y”。 使用有形的、客观的、明确的术语。对于观察者来说，目标是否已经实现应该是显而易见的。研究表明，更具体的目标可以带来更好的表现和更高的目标达成。 设定关键结果的小贴士： 每个目标确定三个关键结果。 关键结果表明可衡量的里程碑，如果实现，将直接推进目标的实现。 关键结果应该描述效果，而不是活动。如果关键结果包含“咨询”、“帮助”、“分析”、“参与”这样的词，那么是在描述活动。相反，要描述这些活动的效果，例如，“在3月7日发布客户服务满意度的水平”，而不是“评估客户服务满意度”。 可衡量的里程碑应该包括完成的依据，这些依据应该是可用的、可信的和易见的（discoverable）。 避免OKR书写错误 设定OKR，即制定明确的目标，和可衡量的、达成一致的结果，能推动团队取得好的成绩并且使组织专注于最重要的优先事项。写得不好的OKRs会产生混乱的策略，破坏内部指标，导致团队专注在维持现状。
2020/7/28
articleCard.readMore为什么要学习Certified Scrum Master（CSM）并续费证书
Scrum联盟了解你作为Certified ScrumMaster®所面对的障碍壁垒。获得认证是敏捷之旅中的第一步，我们在这里为你提供独家的好处，以帮助你持续进步。让我们与高质量培训、资源、工具以及全球最大的、活跃的Scrum认证社区一起前行。仅在你拥有ScrumAlliance认证后才能使用所有这些好处。 1）专用工具 更新你的认证将授予你 使用各种工具的专有权限。 诸如” Comparative Agility Personal Improvement（PI）”之类的工具仅提供给Scrum Alliance现有的Certified ScrumMaster。通过认证的ScrumMaster可以使用此工具评估其当前的技能水平，找到成长的机会，并通过社区与同行进行讨论。在社区委员会中，你会发现可以直接与认证的敏捷专家联系。你在PI工具中找到的资源将帮助你成长为ScrumMaster，为你提供在团队中取得成功所需的技能以及其他更多的职业机会。该 ScrumMaster的PI工具 -包括社区委员会- 仅适用于当前有效的认证ScrumMaster 。 有效的ScrumMaster认证中包括 赠送订阅”比较敏捷”，价值每年299美元。该工具专注于团队开发，并利用了全球最大的敏捷评估数据库。你将能够快速进行基准测试并收集信息，获取见解并为你的团队和组织采取行动。与其他敏捷组织相比，这将使你能够评估敏捷团队的绩效，从而为整个公司带来持续改进的思想。 2）认证和培训 学习可能是你敏捷旅途中最艰难的部分之一。通过认证，你可以获得行业领先的教练、资源和培训。Scrum联盟认证是敏捷社区中最受认可的一些认证。我们的课程会定期更新，以确保你了解最新的敏捷和Scrum最佳实践。由行业专家培训师主持的课程将使你受到教育和启发。NPS得分这个维度，我们为CSM培训师的平均得分为+81而感到自豪。你可以通过投资敏捷认证来开始成为认证的ScrumProfessional®（CSP）的途径。 通过证明你对敏捷之旅的奉献精神，脱颖而出成为申请人。我们的课程包括访问授权内容、培训、网络研讨会和志愿者机会，这将使你获得Scrum教育单位（SEU）。需要获得SEU来续费你的认证。这很容易帮助你在市场上保持竞争力。当你通过Scrum Alliance认证后，你将加入一个拥有超过一百万名认证会员的社区。你可以放心所学的内容是基于行业中最新的Scrum教育标准。 3）社区和支持 最后，我们了解 社区 是成功学习和分享你在此过程中获得的知识的关键。在32个国家/地区拥有 150多个用户组，你可以与世界各地的敏捷和Scrum从业人员连接。与敏捷社区同步将为你提供可以验证你所做的艰苦工作的经验。有了所获得的知识，你便可以自由地塑造Scrum的未来，改变你的工作世界！通过志愿服务机会，你将可以直接服务于敏捷社区。除了我们的面对面聚会和虚拟聚会外，Scrum Alliance社区还可以帮助你在事业中蒸蒸日上。 访问 中国敏捷社区小组 - 由Scrum 联盟支持 Scrum Alliance是501（C）（6）非营利组织，这意味着你的续费可以帮助推动世界各地的社区和用户群体，包括服务于欠缺的社区。我们的使命是帮助每个想要改善Scrum和敏捷之旅的人。我们正在改变工作世界。立即续费你的认证以支持全球新的Scrum和敏捷社区 。 原文 Scrum联盟英文链接
2020/7/26
articleCard.readMore敏捷漫画 010
规模化敏捷大对决 The Scaling Agile Showdown 在底特律一个隐秘的地点，准备下去啦 规模化敏捷大对决。 Alarmin’ Craig (LeSS) vs. Don Leff (SAFe) 哟，是Don Leff，我会让匆忙的人变得脆弱。（猜一猜谁创建了最流行的规模化敏捷框架？） 摇起你的满头白发，就像假发一样。（Craig的技能好像是LeSS的组合水平，根本不存在） Man，你用无意义的愿景过度复杂化了事情。（而我采用清晰的产品定义简化了组织）我有个人魅力，甚至我的对手都知道（SAFe就像你，Leff：庞大、沉重并且缓慢） 我普及了大房间规划，那真的是发自内心的罪过吗？（你应该要感谢我，大公司都开始关心规模化敏捷了！）但是你仅仅把已有的最佳实践很好地打包进一个金字塔计划。（你这不是敏捷，你只是想卖课程赚钱！） 作者评论 非常感谢Dean Leffingwell，Craig Larmann和Jeff Sutherland等人建立了规模化敏捷的框架，因为这使许多大公司（许多非软件开发的公司）都接受了敏捷性原则和价值观。这些思想领袖使企业能够从软件部门开始敏捷实践，从而敏捷也覆盖了跨越多种开发类型的企业级别。 我们必须记住，“规模化敏捷”不是一维问题的解决方案； 在选择SAFe，LeSS，Scrum @ Scale，Nexus，DAD或其他之前，我们必须帮助组织真正地了解为什么要在选择框架之前进行规模化敏捷。理想情况下，本着学习的精神，我们应该启动几个扩展框架的试点，以便在做出选择之前确定最适合我们企业的框架。 并记住先钉下去，再扩展。 译者评论 每一种规模化敏捷框架都有其拥趸，每一种框架都有其用处。（一无是处早就被人放弃了）个人是非常推荐LeSS框架。因为LeSS框架： 足够的简单 完全是基于系统思考，甚至框架本身就是系统思考的因果回路图（CLD）推导出来的。 产品导向，技术实践为重 其他的规模化敏捷框架，有熟悉的朋友也可以来谈一谈。 读者评论 对于今天的漫画，你有什么想说的呢？ 参与讨论，请扫码加入”敏捷家”微信群 原文链接
2020/7/26
articleCard.readMore敏捷漫画 009
在家上学 Homeschooling 由于新冠疫情我们都在家，你妈妈和我都同意最好我们在家上学。 我想学习造小汽车。我想知道为什么太阳那么炎热。 很棒的建议，但我们先从一些更好的内容开始…… 今天，你们将学习验收标准（Acceptance Criteria）和完成的定义（Definition of Done）之间的区别。 作者评论 如果敏捷、快速试错、精益创业和PDCA循环等主题背后的思想观念（应该基于现代发展的概念）实际上是孩子们在学校学到的东西，那将会有多棒？ 因此，如果您因COVID-19疫情而被迫在家工作，并可以自由安排自己的时间，那么现在是时候让孩子们学习一些实用的知识了！ 除非他们整天都在远程学习，否则现在您就有机会向年轻人灌输您认为他们应该学习的课程。 因此，抓住机会，告诉他们验收标准（AC）是完成的定义（DoD）的一个子集，或者现场（Gemba）的重要性。 如果您需要，我们甚至可以考虑创建供儿童学习敏捷的材料。 译者评论 家庭教育如何应用敏捷，已经有越来越多的伙伴在进行尝试了。 你有尝试吗？ 这里有一个TED视频讲解敏捷家庭，或许对你有启发。 读者评论 对于今天的漫画，你有什么想说的呢？ 参与讨论，请扫码加入”敏捷家”微信群 原文链接
2020/7/25
articleCard.readMoreScrum Master是否需要懂技术
我要提问 这是一个系列博客文章，回答敏捷中常见问题。查看所有常见问题。今天回答的问题是： Scrum Master是否需要懂技术？ Bob的观点 Scrum Master需要懂技术，而且是一定要懂技术。不懂技术的Scrum Master很难成为一名优秀的Scrum Master。如果你想成为敏捷教练，或许不懂技术还行得通，但是Scrum Master不懂技术是不行的。具体还可以参考之前的博客文章，Scrum Master和敏捷教练之间的区别。 原因1： 不懂技术的Scrum Master很难融入团队。 原因2： 不懂技术的Scrum Master很难帮助团队在开发（工程）实践方面发展。 原因3： 不懂技术的Scrum Master很难帮助团队发现技术的潜在风险或障碍。 不懂技术的Scrum Master很难融入团队 开发团队成员之间沟通的时候，多半会使用技术术语，如代码仓库、技术债、重构、vs code等等。如果听不懂团队说的是什么，就很难了解问题或背景，从而很难融入到团队中去。所以作为Scrum Master，至少需要了解： 常用技术术语 软件开发生命周期 常用的技术工具，等等 不需要Scrum Master成为代码管理的专家、重构专家，但一定要知道这是什么。 不懂技术的Scrum Master很难帮助团队在开发（工程）实践方面发展 如果一名Scrum Master不懂技术，那么他也很难了解或掌握软件开发行业的最新工程实践（开发实践）。那么作为Scrum Master，如何帮助开发团队认识到当下行业有哪些最新的提高效率的开发工具、工作实践呢。 Scrum Master的关注度不仅仅是团队、产品负责人，还需要关注组织和开发实践。参考Scrum Master和敏捷教练之间的区别中Scrum Master关注度一节。 不懂技术的Scrum Master很难帮助团队发现技术的潜在风险或障碍 最后，如果Scrum Master不懂技术的话，他也很难有技术的感觉，从而很难敏感地发现团队内的潜在技术风险或障碍（不一定是真的风险，但有时候一句话就可以点醒团队）。 综上所述，作为一名Scrum Master一定需要懂技术，而且需要是懂大量的技术（不一定需要很深入）。 职场泥石流的分享 以下来自职场泥石流分享的总结，感谢小新同学（谢晓强）的努力。 之前在群里参与讨论过Scrum master与技术间关系的一些问题，从群友那里得到不少启发，其后有机会能在前两天连线Ethan黄老师，直接就这个问题展开了一些辩论，又聆听了黄老师对一些相关问题的分析与解答，让我对问题的认识又深了一些，这篇文字是对之前视频的回顾总结，加上一些我自己的思考。如果我对于黄老师的观点有引用错误的地方，或者大家认为我的观点有何不对之处，欢迎批评指正。 视频的最开始其实是关于SM懂技术是利大于弊还是弊大于利的一场小型辩论，不过我想先不记录这个，先记录黄老师后面回答的几个问题，然后再回到最开始的这场辩论，这样理解起来可能会更好。 问：没有技术背景的SM感觉无法融入团队怎么办？ 针对这个问题，黄老师首先指出这种情况非常普遍，感到fear也是正常的，他自己也有过这样的经历。面对这种情况： 第一个是要想到每个人的知识面都是有范畴的，要扬长避短，同时你现在不会技术不代表以后不会，这种fear也是你学习的动力； 第二个是要弄明白，这个fear是不是有可能是不必要的，因为在这个行业里或技术里你没有积累，并不妨碍你成为一名好的SM或教练，你可以通过学习掌握软技巧，如有效倾听与强力提问、还有学习的能力，来发挥自己价值，融入团队。 问：技术能力非常强的人，他来做SM会遇到哪些问题？ 针对这个问题，黄老师回答问题在于他可能忍不住涉入到技术问题中去，反而可能忽视了本来的职责。解决的办法就是要管住手管住嘴。但现实中当你越界时你自己往往是没有知觉的，所以就还有一些实践小技巧，比如你们团队间可以协商出某种方式来提醒你越界的事，如订做一顶大牛帽子，只有当你带上这顶帽子时才能扮演技术专家的角色，如果你不自觉的扮演了技术专家的角色的话，就要予以一些处罚，比如请喝咖啡等等。 总结一下，就是你作为一名SM，如果你很懂技术，你不是不能涉入到技术中去，只是你要有一种边界感，知道什么时候你是在扮演技术专家的角色，什么时候又该回到SM的角色。 记录完这两个问题黄老师的回答后，我想可以回到最开始的小辩论上来了。 “Scrum Master懂技术是利大于弊还是弊大于利” 虽然黄老师是站的正方，但我觉得黄老师其实心里还是向着反方的，哈哈。言归正传，如果做个比喻，我认为这个辩题，其实是类似于贝壳的东西，贝壳本身并不珍贵，珍贵的是贝壳辛苦酝酿出的珍珠，而辩题酝酿出的珍珠，其实就是它延伸出的一系列问题。
2020/7/24
articleCard.readMoreCertified ScrumMaster (CSM) 培训学员总结 - 曹天宇
作者：曹天宇 Scrum指南读后感 本人从事传统汽车行业，敏捷经验或scrum经验为0，甚至没有软件开发经验，参加本次培训目的是对敏捷开发有个入门的了解，并结合传统汽车行业的开发流程做一定的思考，因为现在汽车上也会涉及到越来越多的软件。 以下是看完Scrum指南后自己归纳的重点（理解还是更多基于理论层面）： Scrum是一个框架 ，用于开发 交付 持续支持复杂产品的，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付最高价值的产品。 Scrum 框架由Scrum 团队以及与之相关的角色、事件、工件和规则组成 Scrum的应用：最初是为了管理和开发产品而开发的 Scrum 的精髓在于小团队 Scrum 基于经验过程控制理论 Scrum 采纳一种迭代、增量式的方法来优化对未来的预测和控制风险 三大支柱：透明，检视，适应 4个正式事件： Sprint计划会议 每日Scrum站会 Sprint评审会议(review) Sprint回顾会议(retrospective) Scrum价值观：承诺commitment，勇气courage，专注focus，开放openness，尊重respect Scrum团队：产品负责人 + Scrum master + 开发团队， 跨职能的自组织团队 产品负责人：将开发团队开发的产品价值最大化，产品负责人是负责管理产品待办列表的唯一负责人 产品待办列表的管理包括： 清晰地表述产品待办列表项 对产品待办列表项进行排序，使其最好地实现目标和使命 优化开发团队所执行工作的价值 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作 确保开发团队对产品待办列表项有足够深的了解。 为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定 开发团队：负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。在 Sprint 评审会议上，一个“完成”增量是必需的。只有开发团队成员才能创建增量。开发团队由组织组建并得到授权，团队自己组织和管理他们的工作， 规模3-9人 特点： 自组织的 跨职能的 不认可开发团队成员的任何头衔，他们都叫开发人员 不认可开发团队中所谓的“子团队“ 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队 Scrum Master: 负责根据 Scrum 指南中的定义来促进和支持 Scrum， 服务型领导 服务于产品负责人： 尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域； 找到有效管理产品待办列表的技巧； 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项； 理解在经验主义的环境中的产品规划； 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值； 理解并实践敏捷性 按要求或需要引导 Scrum 事件。 服务于开发团队：
2020/7/20
articleCard.readMore敏捷教练和Scrum Master - 敏捷转型中的两个重要角色的对比
我要提问 这是一个系列博客文章，回答敏捷中常见问题。查看所有常见问题。今天回答的问题是： 什么是Scrum Master，什么是敏捷教练，他们之间有什么差别？ 如何转型成为敏捷教练？ 本文将重点描述敏捷教练和 Scrum Master 这两个角色，以及他们之间的关系和对比。 Scrum Master Scrum Master 是一个全新的角色，是在《Scrum指南》中定义的。这个角色（Scrum Master）不是团队领导者，也不是项目经理，更不是经理。请不要把 Scrum Master 与现有的团队（或组织中）的角色进行映射。因为你找不到这种映射。 Scrum Master 在组织中教 Scrum，并可以帮助团队进行 Scrum 落地实践。Scrum Master，顾名思义，精通 Scrum， 对于 Scrum 有深刻理解，能够指导团队成员更好地产出更高价值的产品。 Scrum Master 是反馈环中重要的角色（另外一个反馈环是 Scrum 中的事件），他是一个支持角色，更像是团队的一面镜子，帮助团队识别出现在的问题，从而能够走向“完美”的目标。 想要对 Scrum Master 这个角色有更加深入的学习，可以看一下我讲的 Certified Scrum Master (CSM) 课程，这个课程是 Scrum 联盟的认证课程，可以为你的职业带来突破。 Scrum Master 角色的描述 – 以下摘自《Scrum指南》 什么是Scrum Master Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。 Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。
2020/7/20
articleCard.readMore谈谈敏捷中的那些模式
敏捷中的模式与反模式 本文的内容来自于7月10日我在“艾威网校”的一次分享。 开始先简单自我介绍如下：（欢迎扫码获取ppt） 本文主要分为四个部分： 什么是模式语言及反模式语言 敏捷中的模式语言（Scrum Patterns） 敏捷中的反模式语言 回归本质 什么是模式语言和反模式语言 模式（英语：Pattern，源自法语：patron），在物体或事件上，产生的一种规律变化与自我重复的样式之过程。 在模式之中，某些固定的元素不断以可预测的方式周期性重现。最基本而常见的模式，称为密铺，具备重复性以及周期性两大特征。找寻出固定模式是人类基本的认知功能之一。 – 摘自维基百科 在1977年的《A Pattern Language》一书中，Christopher Alexander提出了模式语言的概念。在豆瓣中的图书介绍如下： 克里斯托弗·亚力山大是美国杰出的建筑理论家。由他领衔撰写的《建筑模式语言》一出版就受到建筑界的广泛重视和高度赞誉，并对建筑业产生了深远的影响。 《建筑模式语言》别出心裁且有根有据地描述了城镇、邻里、住宅、花园和房间等共253个模式，提供了一幅幅设计、规划、施工等方面的崭新蓝图，构思新奇，妙想迭出，不同流俗。 作者写道：“我们深信无疑，本语言要比一本手册、或一位教师、或另一种可能的模式语言略胜一筹。这里的许多模式看来在今天和以后的500年间将成为人性的一部分，成为富有人情味的行动的一部分。”诚如美国《建筑设计》一则评论所说：这也许是20世纪出版的关于建筑设计的最重要的一本书了。 这本书的生命力在于“以人为本”。它是此书的主题思想，像一条鲜艳的红线贯穿始终。各模式的字里行间洋溢着浓浓的人情味和对人的无微不至的关爱，如保护生态环境，如何绿化美化城镇和住宅，反对建筑风格的千篇一律，鼓励人际交往，强调人、社会和自然环境三者的和谐统一，等等。 所以不论是在敏捷转型中，还是软件开发中，亦或是建筑行业或我们身边，都会存在着许许多多的模式。而本文就是要和大家一起来探索一些敏捷转型中的模式（以及反模式）。其中的一些模式摘自于《A Scrum Book》一书，书中提供了94中Scrum的模式，下面我会结合实际工作经验介绍其中的4种。 反模式 反模式（anti-pattern）也是一种模式，最早是在软件工程中提出的，反模式指的是在实践中经常出现但又低效或是有待优化的设计模式，是用来解决问题的带有共同性的不良方法。按照《反模式》一书的作者的说法，可以用至少两个关键因素来把反模式和不良习惯、错误的实践或糟糕的想法区分开来： 行动、过程和结构中的一些重复出现的乍一看是有益的，但最终得不偿失的模式 在实践中证明且可重复的清晰记录的重构方案 – 演绎自维基百科 敏捷中的模式语言 下文主要描述四种敏捷中的模式语言：（分为两类 - 产品组织和价值流） 回顾会（产品组织） 小吃神社（产品组织） 障碍清单（价值流） Scrum板（价值流） 回顾会 回顾会是敏捷中至关重要的一个会议（也是敏捷的本质，在最后的总结中我会再次提出这个重点）。如下图，如果忙于交付而忽视了改进，则从长期来看一定是得不偿失。 对于团队而言，回顾会就是每个迭代结束前团队在一起反思团队中关于人、关系、过程和工具的情况，根据上述情况制定具体的改进计划。上图中采用的方法是： Start, Stop, Continue 开始尝试新的方法 停止无效或低效的方法（或工具） 继续使用良好的工具（或方法） 另外对于个人而言，也是需要不断的回顾总结与反思。这里是我个人的每周总结。 小吃神社 团队都很难独立存在的（尤其在大公司中），于是日常工作中团队（或团队成员）总是会受到不同人的干扰与打断。被打断后要再重新开始刚才的工作就需要思路能接上，这是一个很难的事情。所以对于团队需要有一个缓冲地带，就是下图中的“小吃神社”。（这个名字来自于日语） 注：小吃神社不是茶水间，这个区域离团队很近，但不至于影响到团队的其他人工作。 这个缓冲地带对于团队来讲非常重要，任何问题都不要直接去打断团队的节奏（除非是生产系统挂了）。而是大家可以在小吃神社这里进行讨论。这个模式的前提是，团队太容易也太频繁被打断了。 障碍清单 工作中每个人都会碰到不同的问题、障碍。敏捷中经常也会提倡在每日站会上提出遇到的问题障碍。然而仅仅提出并不是很好的做法，更好的做法是可以创建一个障碍清单，用于收集并排序团队中的障碍。 这个模式的好处是： 可视化团队所有的障碍问题 排序（根据风险评估）后，根据顺序来一次解决障碍 每个障碍可以注明跟进人 Scrum板 Scrum板如下图，是一个白板，用于可视化团队在迭代内的进度。团队每日站会就围在Scrum板的前面，每个人回答三个问题。
2020/7/14
articleCard.readMoreScrum反模式：微观管理
译者：Fish 审校：Bob 原文链接 设计模式是对重复出现的问题的解决方案的描述，概述了解决挑战所必需的要素，且不提示读者以特定方式解决该问题。 不幸的是，我们还是会经常看到无效行为的反复出现，这些被称为反模式。 以下是对最常见的一种反模式的探讨：微观管理。 反模式[ 1 ]名称：微观管理 别名：过度控制；监督 规模：单团队或多团队 相关反模式：冲刺燃尽图，速度很重要，时间跟踪，个人激励 潜在解决方案： 服务型领导或仆人型领导 冲刺黑匣子 关注成效而不是产出 领导层专注于战略和创造有效的工作环境 为什么会发生微观管理 刚接触Scrum的人通常很难把握有效管理者、ScrumMaster和产品负责人之间的控制界限。这是一个至关重要的考虑因素，因为敏捷的核心是试图去帮助一群人成长为一个有韧性，高效能的团队。这些角色不仅能够促进这种成长，也能阻碍这种成长。允许团队自组织进而蓬勃发展是一个关键因素。 无论您是ScrumMaster还是经理，一旦发现某事可能要出问题，就会想要提供帮助。这可以理解：您是出于好意。但您没意识到这是正在进行微观管理；您觉得这只是给些建议，提供些帮助、点子，使其避免风险。然而，微管理有多种形式：管理层给出建议或直接向团队成员下达命令；利益干系人指导产品负责人用户故事；经理们坚持以某种方式做事，因为他们以前已经做过很多次；还有很多……这些行为都有一个共同的特征：那些并不直接做事的人在试图影响真正做事的人该如何做事。 微观管理在Scrum环境中有很多存在方式。接下来，按角色概述常见的几种。 ScrumMaster的微观管理： 将工作分配给团队成员，而不是鼓励他们进行自组织。当ScrumMaster被赋予ScrumMaster和Project Manager的双重角色时，这种可能性更大。 运作每日Scrum，而不是引导团队开展会议。 将Daily Scrum变成状态报告，而不是团队协作的契机。 将自己的想法和观点注入回顾会中。 告诉团队成员如何工作。 告诉团队成员如何解决问题，这样会损害团队自己解决问题的能力。 告诉团队成员问题出在哪里，而不是帮助他们自己发现问题。 产品负责人的微观管理： 在Sprint中添加新工作，并要求立即完成。管理层有时也会这样做。 参加Daily Scrum以获得状态更新。（Daily Scrum用来帮助团队在一天中进行协作和集中精力。如果团队邀请产品负责人，则产品负责人必须记住这一点，并且不得干涉。） 将Daily Scrum用作向团队询问其工作的机会。 监督团队，检查所有的细节。（一个好的产品负责人应该赋能团队，小事团队可以自己决定。） 管理层和其他干系人的微观管理： 参加Daily Scrum并注入自己的想法，称其为”建议”。（管理层的大多数建议会被自动视为命令。） Daily Scrum中有管理人员出席，也会使人们将事件转变为状态报告事件。团队成员会不自觉经常去看管理者，而不是看同伴。届时，Daily Scrum便成了以管理者为中心而非团队。 管理者，特别是高管的建议通常被当做命令，因为这些人控制团队成员的绩效评估，薪水增加和长期雇佣状态。团队成员自然会去取悦那些拥有权力的人。 要求ScrumMaster在Sprint中频繁更新进度。 使用Sprint Burndown图监察Sprint期间团队的进度。 将Burndown / Burnup /累积流图视为进度的度量标准，而不是将其用作预测工具来查看Product Backlog中的哪些项目将完成。 要求更高的速度或要求团队更快。（团队最终会更快，但只能专注在提高技能和工作质量。） 告诉团队如何工作。 告诉产品负责人如何写用户故事。 将ScrumMaster视为差事。 提示：告诉/分配/应该这样的词是发生微观管理的警告信号！
2020/7/12
articleCard.readMore敏捷漫画 008
经理与冲刺列表 Manager vs. Sprint Backlog 我们的冲刺列表不仅包含来自产品待办列表中的用户故事，还包含缺陷、风险、和改进项。 所以任何事情都可以加到冲刺列表中吗？是的，如果团队同意的话，但是…… 那么，请新增：作为经理，我想要你们用小时来计算迭代速率，这样我就可以把团队效率汇报给高管（executives） 作者评论 Scrum指南指出：“Sprint列表是为Sprint选择的产品待办列表条目的集合，以及交付产品增量和实现Sprint目标的计划”。我们还看到，冲刺列表包含缺陷、减轻风险的措施以及根据先前的回顾改进Scrum团队工作方式的活动。 在上述经理的命令中，我们看到了几种反模式；使用组织层次结构告诉团队将某个条目包括在冲刺列表中，该条目的内容（可能）既无助于团队的Sprint目标也不是回顾会的结果，并且请求的动机在于衡量和报告团队的“效率”。至少，经理正确传达了用户故事的声音…… 译者评论 这里主要提到了一个反模式，即经理的副作用。那么这里并不是说经理（或管理层）不重要，而是在敏捷转型中，他们不用进行微观管理。那么对于经理（或管理层）需要做哪些事情呢？ 在《Scrum精髓》一书中有提到，对于敏捷转型中的经理，最主要的工作有： 塑造团队 培育团队 调整并改造环境 管理价值流 塑造团队 塑造团队中有如下几个关键点： 定义边界 提供清晰且鼓舞人心的目标 组建团队 改变团队的人员组成 授权团队 培育团队 培育团队包括： 激励团队 发展团队能力 建立领导力 保持团队的完整性 调整并改造环境 调整并改造环境会包含以下内容： 传播敏捷价值观 移除组织层面的障碍 内部的多个团队保持一致 与合作伙伴（如上下游）保持一致 管理价值流 管理价值流包括： 立足于系统的角度思考问题 管理经济情况（大白话及是否划算） 度量与汇报 所以管理者们，请不要进行微观管理，有大量你应该做的事情。 读者评论 对于今天的漫画，你有什么想说的呢？ 参与讨论，请扫码加入”敏捷家”微信群 原文链接
2020/7/12
articleCard.readMore敏捷漫画 007
社交隔离 social distancing 明天起，我们彼此不能离得很近。必须通过社交隔离（social distancing）来阻止COV-19的传播。 好像产品负责人已经尝试让曲线变平。现在接下来的几个迭代将找不到他了。 作者评论 我们所有人都必须竭尽所能，通过社会隔离、在家工作和支持那些冒着生命危险保护我们社会中最弱势群体的人，来防止COVID-19传播。 我们经常看到产品负责人与开发团队之间的距离似乎很遥远，最糟糕的是甚至完全无法找到产品负责人。在此之前，作为敏捷教练和Scrum Master，我们必须帮助PO在进行面向外部的活动（例如与最终用户和客户进行需求研讨会），以及进行面向内部的活动（如与团队进行产品待办列表梳理）之间找到微妙的平衡。 如果产品负责人与团队没有在一起，则确保可以找到产品负责人的一种方法是，每天产品负责人有几个小时的时间窗是团队可以随时能找到的（如打电话的空闲时间）。 译者评论 这个漫画除了描述 COV-19 期间的社交隔离，更重要的描述了产品负责人与开发团队之间的协作问题。 一般情况下，产品负责人在开发团队想要找他的时候很难出现，（就像现在的社交隔离一样）而实际中产品负责人不仅仅对外合作（收集客户需求，与客户互动），还要与开发团队紧密协作（澄清开发团队遇到的问题）。 产品负责人，请不要“消失”…… 读者评论 对于今天的漫画，你有什么想说的呢？ 参与讨论，请扫码加入”敏捷家”微信群 原文链接
2020/7/11
articleCard.readMore国王的晚宴 King's dinner
作者：Ron Jeffries 译者：年志君 （微信公众号：敏捷家） 背景 这个小故事根据资源、质量、范围和时间的关键度量变量，来描述了一个有效的团队运作方式。故事由罗恩·杰弗里斯翻译自原始的巴比伦楔形文字。 开始啦 从前 … 有一个伟大的国王，他想为几千位最亲密的朋友举行国宴。他把首席工匠叫来，告诉他晚餐的安排。国王描述了他想要最好的餐桌摆设，全部镶入黄金，并镶嵌有错综复杂的珠宝。首席工匠画了一些草图，并与国王就摆设达成了一致。他们同意在几周后再见面，看看餐桌摆设制作的进度计划。 几个星期过去了，首席工匠来报告。他向国王展示了一个时间计划，该计划包括创建摆设的原型，国王的审查，以及最终餐桌摆设的展示。计划表显示，晚宴布置将在11月完成，但国王愿意在10月举行宴会，此时天气仍然晴朗。首席工匠同意在下次会议之前调整工作，以便在10月前完工。 按计划，首席工匠带着原型和修订的10月完工的生产计划展示给国王。而且，工匠还建议与国王要定期见面，以检查进展情况。国王审阅了由于工期缩短而简化设计的原型。国王要求在盘子上要有更多的小天使，在镶嵌的珠宝上有更漂亮的雕刻，在刀叉上增加更复杂的卷轴。首席工匠抗议说，这些新的功能将延迟完工计划，但国王提醒他谁是国王，谁不是。首席工匠退了出去。 落后了 在下一次的项目审查中，事情已经明显落后了。准备好的珠宝太少了，盘子也不够完整，刀叉也做得太少。国王要求工匠们更加努力地工作。首席工匠抗议，但国王再次提醒他们的相对地位。国王要求增加审查的次数，甚至比已经同意的还要频繁。 在下一次审查中，任务并没有完成太多。国王坚持要去现场看看正在做什么。第二天他到了，工匠们有点紧张，但他们知道他们自己的技艺，并且他们大多数都像往常一样努力工作。 “那个人在干什么?”国王指着一个明显的懒鬼问。 “国王啊，他正在休息。”工匠首领回答说。 “这是对我们时间的极大的侮辱。” 国王斥责道: “他们应该在晚上休息，而不是在工作的时候。” “国王啊，就照您说的办。”工匠首领回答说。 国王问:“那边那个人在干什么?” “国王啊，他在磨刀。” “又是在浪费我们的时间。难怪你一事无成。从今以后，工具要在夜间磨，不能在工作中磨。” “国王啊，如你所愿，”首席工匠叹息道。至此告别，直到国王下次审查。 在下一次审查的中途，首席工匠找国王的首席管家，要求增加一些新的学徒帮助完成任务，特别是磨刀的任务。这位管家考虑到国王的财政预算，以管家古老的方式解决了这个问题，没有回应首席工匠的请求。。 在下一次审查时，实际上完成了更多的工作。国王视察了一堆已完成的盘子和器皿。起初，他满意地笑了笑，但当他更仔细地查验时，他的微笑变成了皱眉。 他咆哮道：“这些盘子，这些小天使很粗糙，不像早期的盘子那样精致。如果你就这么做了，客人们是不会有什么好印象的。” “国王啊，工作粗糙，是因您的命令使用了钝的工具。” “我没有命令你做差劲的工作，我命令你不要浪费时间！ “噢，国王，”工匠解释说，“就像陛下没有好的食物和环境就不能举办一个好的宴会一样，我的工匠们也不能用粗糙的工具创造出好的艺术。” “我必须把一切都告诉你吗?”国王尖叫道。“可以让别人磨工具吧!” “国王啊，我已经为此请了新的学徒，但您的管家没有答应我的请求。” 国王咆哮道:“工匠，不要拿这些内部事务来烦我。我可是国王。让工匠们在需要的时候磨砺他们的工具:但他们必须通过加班来弥补时间。” “哦，国王，就照你说的办吧。”首席工匠闷闷不乐地回答。 国王回到视察的地方。很快，他又被激怒了。 “这些盘子，很多还没有雕花的珠宝。这里出什么问题了?” “哦，国王，珠宝损坏的情况越来越严重了。”首席工匠答道。 “是什么导致了这一切，”国王大叫道，”你的人如此无能吗？ “恕我直言，国王陛下，珠宝雕刻是一项微妙的工作。由于没有频繁的休息时间，雕刻者眼睛疲劳，双手颤抖，导致工作失败。 “你这个傻瓜。”国王大声说。“你必须惩罚那些破坏我珍贵珠宝的工人。显然，他们不够小心。” “应该是这样的，”首席工匠鞠躬答道。 在第二次视察时，国王带着怀疑和明显的挑战神气走了进来。当他看到雕刻的质量有所提高时，他平静了一点，当他看到大部分的盘子都镶嵌着宝石时，他几乎高兴起来。然而，随后，他数了数已完成的工作，发现尽管质量提高了，但完成的工作并不多。 “你现在做错了什么，工匠?”你自己要受什么惩罚呢?” “啊，国王，”首席工匠答道，“我的几个主要的工匠因为您的惩罚而生病了，不能工作了。还有一些人离开自己的王国去了邻国，说他们的工作在那里会更受赏识。结果，我们的工人更少，生产的工作也更少了。” “我命令你的工匠们加班，”国王咆哮道，“难道这还没有改善吗?” “国王啊，事实恰恰相反。同样，也有一些人离开了王国，去寻找一个他们会更受赞赏的地方。留下来的大多来自基层，虽然他们精力充沛，但缺乏做你所要求的工作经验。当他们因为加班而疲惫不堪时，又出现了损坏和无效的工作。” “这是不可接受的!我对你们非常失望，工匠。回到你们的住处，等待我决定你们的命运。” 首席工匠退出了，他确信他的时代结束了。 国王非常担心。那个首席工匠辜负了他的期望，他一定会死的。不过国宴很重要，晚宴布置也必须完成。尽管国王不愿意承认这一点，但工匠还是尽力按照命令去做了。国王决定咨询他的巫师，巫师从小就是他的导师和心腹。 巫师 他还没来得及召唤使者，一声巨响和一团烟雾宣告了巫师的到来。据说，当人们想到他的时候，这位巫师总是知道的。 国王跳了一下后，并没有浪费时间。他向巫师描述了围绕晚宴发生的事情，然后表达了他的担忧。“巫师，我觉得首席工匠违抗了我的命令，必须得死。然而，由于我们无法给他适当的建议，我们是否对这个问题也要承担一些责任呢? 不管怎样，没有了首席工匠，我的工匠们怎么准备晚宴呢?” 巫师伸手从稀薄的空气中抓取了一只鸽子。他拔出匕首，打算仔细观察鸽子的内脏，只是刚好想起自己是在王宫里。他把鸽子塞进一个宽大的口袋里，却打了个响指，发出了短暂的火光，接着是一缕烟雾。他观察着烟雾消散的过程，辨别出只有他才能看到的模式。最后，他转向国王。 “陛下，我研究这些问题已经很久了，可以提供一些见解。我们必须考虑工作的四个方面，而且只有四个方面。这些我称之为资源、范围、质量和时间。不可改变的自然法则与这些方面有关。让我们仔细思考，看看他们之间有什么关系。” 巫师继续说:“我把陛下所要求的工作称为所有任务的总和，即范围。” “一个奇怪的名字，巫师，但我熟悉你的神秘方式。说下去。”国王说。 “现在考虑一下资源：陛下有多少工匠。如果一个工匠失踪了，他的工作或工作范围是增加还是减少呢?” “这要看丢失的工匠是好是坏，以及他被赋予了什么责任。”国王回答说。 国王,您是明智的。然而你的工匠们很有能力,正如你所要求的那样,他们肯定会明智地分担责任。那么,减少资源的结果是什么呢?
2020/7/9
articleCard.readMore敏捷漫画 005
为什么要敏捷？ 我有一些好消息宣布。现在我们终于变得敏捷并踏上敏捷之旅啦！ 我们已经说了好几年了！但是改变了什么呢？ 我已经成功地说服了高层领导，一旦我们变得敏捷，最终我们可以在预算内、预计时间内、范围内开始交付项目！ 作者评论 每当企业决定引入敏捷原则和实践时，许多敏捷传道者都会感到高兴。但我们知道，这通常意味着更加关注客户需求、业务价值和员工敬业度。但是，如果出于“错误”的原因而采用敏捷，那么转型工作将导致低于标准的改进。 因此，我们有责任对管理层进行教育，以发现他们想变得敏捷的真正的目的（“为什么”），他们期望得到的改善。如果他们希望在通常的瀑布式环境中获得较少的项目变更请求，那么他们将感到失望。 一个方向是要查看团队的管理层是否由于“敏捷转型”而不会改变任何行为；如果没有，那么敏捷计划可能仍将基于团队不破坏范围 、成本和时间或其他瀑布KPI的铁三角的能力进行评估。 译者评论 最近有小伙伴（Jackie）翻译了一篇 Ron Jeffries 的国王的晚宴，有效地描述了成本、时间、范围和质量之间的关系。 读者评论 对于今天的漫画，你有什么想说的呢？ 参与讨论，请扫码加入”敏捷家”微信群 原文链接
2020/7/9
articleCard.readMore敏捷漫画 006
我们就叫它…… 恭喜你拿到 Scrum Master 认证（什么是CSM认证）。团队进展怎么样？ 【实际上非常好。尽管我们在 sprint 中间变更了 sprint backlog ， 也没有 sprint 目标，产品负责人也不想进行 sprint 评审，以及团队憎恨回顾会……】我真的感觉我们理解了敏捷的精神。 所以……我们在做什么呢？ 我们同意称之为看板（kanban）。 作者评论 《Scrum指南》指出，Scrum 是轻量级的，易于理解且难以掌握。而且，这是对的。 尤其是在规模化 Scrum 时，随着 SAFe 的普及，许多新团队开始用 Scrum 的方式工作，因为这已经成为敏捷发布火车（Agile Release Train）的一部分，该火车由 Scrum 团队和看板团队组成。我们经常看到团队很快得出结论认为 Scrum 不适合他们的工作性质，因此决定将自己称为看板团队。 我们必须记住的是，看板本身就是一个框架，而不仅仅是用了 Scrum 就半途而废，在Scrum中，您仅使用看板的一部分，而没有其他用途。看板就是要管理流程，减少交货时间（leading time）并确定需要改进的地方。因此，让我们停止（滥用）此潜在强大的框架，作为未进行适当变革的借口。 译者评论 Scrum 中的“看板”本质上并不是 Kanban ， 而只是一个白板（大部分情况下如此）。只是用白板来进行可视化的部分，而 Kanban 的其他核心原则与理念并没有融入进来。所以如果只是一个白板，请不要叫它 看板（Kanban）。 这个概念和误用 Scrum 是一样的。如果我们没有 sprint review, 没有回顾会，没有每日站会，这还是 Scrum 吗？（显然不是的！） 读者评论 对于今天的漫画，你有什么想说的呢？ 参与讨论，请扫码加入”敏捷家”微信群 原文链接
2020/7/9
articleCard.readMore敏捷漫画 004
燃尽图 Wow，我从来没看见过如此完美的燃尽图。你们确实设法与团队保持了一致。 这不是我们的燃尽图！这是我们公司的股价！（由于COVID疫情的影响） 作者评论 随着全球股市暴跌，燃尽图的视觉相似性显而易见。 一个成熟的Scrum团队对他们的速度有很好的了解。 这些交付的故事点的流动可以看作是实际的燃尽图，并可以与冲刺燃尽图上的预测“理想”的燃尽线进行比较。 团队无法达到理想的燃尽线有很多原因：比如过度承诺、依赖性、PO找不到和不切实际的完成的定义。燃尽图反映了所有这些问题，我们作为Scrum Master或敏捷教练的职责是帮助团队克服障碍。 译者（Bob）评论 燃尽图在 2017 年版本的《Scrum指南》中已经拿掉了。因为有很多的方式可以体现出团队在 Sprint 内的进度，燃尽图仅是一种方式，而且反映出来的信息还是模糊的。 参与讨论，请扫码加入”敏捷家”微信群 原文链接
2020/7/8
articleCard.readMore敏捷漫画 003
敏捷滑板车…… 所以，请只做那些最少的必需的工作以满足验收标准（Acceptance Criteria）。没有黄金盘子，因为预算还是非常紧张。记住MVP方法就是有关于思维方式，因此先从滑板开始，从客户那里获取一些反馈！ 嗯，我们做这些东西干什么？ 作者评论 创造最小可行产品（MVP）的一个众所周知的隐喻是滑板、逐渐演变成踏板车、自行车和汽车（译者注：来自 Henrik Kniberg）。该想法是，客户想要汽车时，我们应该问“为什么”。答案可能是“因为我想从A到B”。因此我们确定了如何以最小的努力来解决此问题，即创建一个滑板，并使团队与客户之间形成反馈循环，以确保滑板能够适当地演变。 如果团队、产品负责人和客户（由于任何原因）无法以可能进行迭代开发的方式实施MVP，则他们最终可能会丢掉太多滑板。如果我们不能将现有的滑板进一步开发到产品的下一个增量，那么从头开始制作踏板车或自行车将是非常昂贵的。 请注意，在这里，我们并不是在谈论基于整套的设计或类似的方法，在这些方法中“扔掉”实际上是积极的并且值得鼓励。 译者（Bob）评论 MVP是一个非常流行的概念，尤其在总理提倡“双创”以来。可惜大多数人都是在误用这个概念。如果MVP无法获取认知，也无法很好的使用起来，那么最终就和图片里一样，变成了垃圾，从而形成了大量的浪费。 参与讨论，请扫码加入”敏捷家”微信群 原文链接
2020/7/7
articleCard.readMore敏捷漫画 002
分布式囤积 大家都知道，由于新型冠状病毒肺炎（COVID-19）的影响，在接下来的几周内公司的执行管理层决定禁止见面的会议。 因此很高兴大家都能在家参加我们的计划会（Sprint Planning）。我们已经进行了很好的梳理会议，所以计划会将非常高效……我们准备好开始了吗？ 是的；是的；没错。 作者评论 不幸的是，如今这是一种可能现实的情况，尤其是如果您与丹麦的Scrum团队合作，在这里政府已经“关闭”了该国（即学校，公司以及所有100多人的聚会），为期两周。 译者（Bob）评论 不幸的是，现在中国也是某种形式的“关闭”。在这波COVID疫情的影响下，大量的面对面的活动、培训、会议被取消，转而是线上的协作与互动。可能接下来的10-20年会有更多的线上协作方式出现。 所以针对线上的形式，你准备好了吗？ 参与讨论，请扫码加入”敏捷家”微信群 原文链接
2020/7/6
articleCard.readMore敏捷漫画 001
项目集白板 The Program Board PI Planning太棒了！所有的团队和干系人都来了，并且我们可以在项目集白板上映射团队之间的依赖关系。 计划进行的怎么样？ 非常好！对齐所有的依赖太棒了……我们还需要这个概述（指的是白板上的依赖关系）一段时间。 作者评论 在组织进行最初的PI计划（PI Planning）（或大会议室计划）之前，每个人都有很高的期望，特别是团队之间的依赖关系可视化和团队之间的对齐。第一个项目集白板最终可能采用的方式，并不一定会辐射出透明度和概述性。 采用潜在的大量依赖关系作为可视化的输入，则随后的重点应该是，通过努力切分特性（垂直）和确保遵循团队的组成（注：特性团队），来最小化（以及理想地）消除这些依赖关系。 译者（Bob）评论 因此我们得出，敏捷转型的第一步是可视化，并且是无情地可视化（即可视化一切无法看到的信息）。这个是至关重要的。有的时候我们不知道如何改进只是由于不知道现在在哪里、现状是什么。 敏捷转型第二步，就是反思并持续改进。可视化之后如果继续无视，那么可视化的目的就完全丢弃了。 参与讨论，请扫码加入”敏捷家”微信群 原文链接
2020/7/2
articleCard.readMoreScrum完整剧本
敏捷快速入门指南 《敏捷快速入门指南》简要概述了我在与团队合作时发现的有效方法，对于那些希望获得一些一般性指南（并非旨在作为说明性准则，但可以作为任何团队工作的基准。大多数快速入门指南都集中在与Scrum相关的主题（Scrum事件）上。其他主题涵盖了作为敏捷教练经常遇到的领域。 Scrum主题 产品列表梳理会议快速入门指南 每日站会快速入门指南 Sprint规划快速入门指南 Sprint评审快速入门指南 Sprint回顾快速入门指南 其他主题： 故事拆分快速入门指南 编写清晰明确的用户故事快速入门指南 Product Backlog Refinement 简介：产品列表梳理会议（也称为需求梳理）不是Scrum指南中定义的活动。然而，产品列表梳理的实践在Scrum团队中是非常普遍，以至于一些从业者认为这是普遍接受的Scrum实践。 定义 产品列表梳理会议是为即将到来的（如接下来的1-2个）迭代（Sprint）准备用户故事的一个持续过程。产品列表梳理有两个主要方面： 由产品经理和产品负责人领导的，需求功能不断定义、完善、澄清以及重新确定顺序； 在Sprint开始之前进行的一次协作会议，以评估新信息，确保准备开发下一组故事。 频率 每个Sprint一次（通常是Sprint中，下一个Sprint开始前的1-5天不等） 注意：某些团队选择每个Sprint进行多次”梳理”会话。如2周的SPrint，可能一周梳理1次。 持续时间 团队应努力在一个小时或更短的时间内完成为期两周的Sprint的产品列表梳理。当故事在产品列表梳理开始之前就被很好地阐明时，团队更有可能在相当短的时间内完成产品列表梳理。（另请参见编写清晰明确的用户故事快速入门指南。） 参与者、输入、输出 参与者 – 产品负责人，ScrumMaster，开发团队 输入 – 主要输入是为即将到来的Sprint预测的用户故事，这些可能是后续Sprint的不错选择。处于就绪状态的用户故事要多于下一个Sprint可能会有所帮助。因此，如果团队确定依赖性，并有了影响多个故事的优先级或工作量的新信息，那么就可以灵活处理。 输出 – 整个团队达成共识，就一组排好序、清晰定义且独立的用户故事达成共识。 活动 产品列表梳理期间的活动通常包括： 查看从当前Sprint中学到的新信息 讨论最快速度、可能速度和最差速度 是否对当前的Sprint进度进行检查 - 我们是否认为我们将完成Sprint期间的所有工作？ 在回答这个问题时，请牢记可持续的步伐 对于团队来说，在Sprint中去现实地评估事情，比等到Sprint结束后再进行任何变更，要好的多（香不香？）。 查看并澄清即将发布的用户故事 讨论并同意验收标准（Acceptance Criteria），以确认双方的理解。以及确认估算大小和拆分太大的故事 提醒：任何故事，如果团队在一个SPrint内无法完成4个，那么就是太大了。 同意下一个Sprint的计划 根据我们的速度预测和大小确定，这是一个现实的计划吗？ 如果对上一个问题的回答为”否”，则拆分故事，或交换优先级相近的小故事，直到团队对计划充满信心为止 注意：另请参阅多年前我写的产品列表梳理
2020/6/16
articleCard.readMore保护隐私的在线黑客马拉松
现在报名 Gitcoin 的朋友，大家好！在过去的几年中，全世界都在不停地争论和讨论个人隐私安全问题。但是，它似乎从未像今年这样对我们社会的平衡与发展产生如此重要的影响。 2020 年绝对是有关弹性（resilience）、数据收集和安全性的一年。因此，让我们一起探寻更好的方法来保存、保护和使用我们的数据。 在 2020 年 6 月 15 日至 2020 年 6 月 29 日之间，我们将为保护隐私虚拟黑客松1开放开源之门！在领先的 WEB3 公司已经创建的隐私空间的基础上，我们将探索平衡用户所有权、控制权和隐私权的解决方案。 从服务于数据经济的 Web3 应用程序，到去中心化的消息传递应用程序，再到加密领域基础设施组件和公正中立的数字货币，更安全、更个性化的未来的基石就在在这里。来吧，在新的个人数据时代留下自己的印记！ 加入我们和 8 个优秀的赞助商，我们一起寻求聚焦于隐私的、以用户为中心的创新解决方案- 奖池超过 25,000 美元！ 您可以设想、概述和设计从数据所有者那里获取价值的方法。 准备成为个人数据方面的黑客吗？ 来吧，没有比现在开始更好的时间了！在此处2注册参与”保护隐私”，并介绍所有注重隐私的朋友过来，一起在保护隐私的市政广场3中来一场头脑风暴。 在 6 月 15 日黑客马拉松开始之前，请了解我们的赞助商并熟悉它们的产品和文档： 海洋协议[4] 海洋协议库和服务可帮助开发人员构建市场和其他应用程序，用于隐私安全地发布、交易和使用数据。 Keep Network[5] Keep 提供了公共区块链和私有数据之间的桥梁。它为区块链开发人员带来了全新的基础设施创新浪潮。 Status[6] Status 发布了一款保护隐私的通讯工具。旨在使信息自由流通，维护隐私安全通信的权利并促进个人主权。 MakerDAO[7] Maker 是 DAI 的创建者，DAI 是一种任何人都可以随时随地使用的数字货币。 Electric Coin Company[8] Electric Coin Company 发起并支持 Zcash 的开发，Zcash 是一种基于强大科学知识的隐私保护数字货币。 NuCypher[9] NuCypher 为保护隐私的应用程序和协议构建密码基础设施。 NEAR 协议[10] NEAR 是一个去中心化的存储和计算平台，其安全性足以管理如金钱或身份这样的高价值资产。 Raiden[11] Raiden Network 是一种链外扩展解决方案，可实现近乎即时、低费用和可扩展的支付。 需要了解更多信息吗？我们将在整个黑客松中全程为您服务，我们将与赞助商共同举办一系列教育研讨会和网络研讨会，因此请务必加入我们！
2020/6/15
articleCard.readMore旧金山区块链周黑客马拉松
现在报名 旧金山区块链周虚拟黑客马拉松 我们很高兴能在Unitize虚拟黑客马拉松上与SF区块链周合作，它将把来自世界各地的黑客聚集在一起，以帮助在DeFi，游戏等领域建立长期的区块链采用。 Gitcoin从根本上相信，要获得真正的采用，我们需要为用户提供独特而引人注目的数字体验。为此，我们希望鼓励大家与业务中最好的人一起工作，以创建可扩展的，高度参与的，持久的平台。 这项活动有很多奖项，赞助商研讨会以及来自整个区块链生态系统的出色导师。我们希望您不仅有机会建立一些很棒的东西，而且在学习和获得加密货币奖励的过程中结识一些很棒的潜在合作者。 到目前为止，赞助商包括Tellor，Terra，NuCypher，Outplay，Nervos和Chainlink。 研讨会时间表： Chainlink研讨会：美国东部时间7月6日，星期一，中午12点- 在此处回复 HACKATHON如何运作？ 查看奖品 访问奖品浏览器，查看由黑客马拉松赞助商发布的奖品。单击每个奖项以显示重要的详细信息，包括提交要求，提交截止日期等。 加入Hackathons聊天工作区 与其他黑客聊天，向发起人和Gitcoin团队提问，找到或创建一个团队，并进行实时交流。单击此处加入聚会！。 通过Gitcoin开始工作 组建团队后，请您的一个队友导航到您计划竞争的每个奖金页面，然后单击”开始工作”按钮。 开始构建！ 建立您的创意，使您的团队实现您的愿景！ 通过Gitcoin提交作品 项目完成后，请点击奖品页面上的”提交作品”按钮/ 现在报名
2020/6/15
articleCard.readMore六大秘籍教你月入50000
今天分享的话题是“六大秘籍，教你月入5万“。其实这个话题有一点点噱头，而实际比这个多不少。咱们总得低调一点，是吧。 背景介绍： 姜信宝（Bob Jiang） - 敏捷家（AgilePlus.co）社区创始人; Certified Scrum Trainer。专业的敏捷讲师、培训师。国内顶尖的Scrum专家。 内容大纲： 背景介绍 6大秘籍 探索方向 职业路径 发展方向 先介绍一下背景。今天晚上给大家介绍这些东西，都是我个人的一些亲身经历，也算是我对自己之前的这些年做一个总结。 感谢 感谢石墨文档的邀请，今天再这里给大家分享“六大秘籍教你月入五万”。后面每周三石墨文档会邀请大咖来分享。下周会分享人力部门的石墨文档的用法。 我今天分享的这些干货的东西，那一方面其实我是介绍我自己的职业生涯，然后也介绍我怎么能赚那么多钱，然后也会结合着我怎么用一下石墨文档来进行各种协作。 我们来介绍怎么赚钱，怎么样的能培养5万月薪的技能。我是2001年毕业的，现在来看已经算是后浪。不对，我这是前浪了，怎么还后浪呢。显然我已经被拍死在沙滩上的那种。2001年毕业的时候，那时候我只有2000块钱的月薪，然后现在能5万（其实不止这么多）。 这中间要培养的技能是今天的重点。我相信每个人来的话，其实都希望自己薪水后面加个0，甚至加两个0。你今天听了我的分享之后，我保证你的薪水后面能加个0，当然不是明天，你得耐得住时间。不能说我今天听你分享，我明天就去跟老板说，我薪水后面加个0。但是我保证在5年后你薪水后面至少能加1个0。我们不要小看时间的力量，有很多事情你是要相信时间的力量，你要不断的去打造技能，这是我个人的一个背景（我也是个2011年才觉醒的前浪，所以相信我，方向对了，5-10年是至少的）。 再来讲一讲整个时代的背景。现在是地摊经济的话，其实之前的话我们互联网的发展其实经历了三大阶段，现在我们当下正处在web 3.0的时代，1.0的时候其实就是2000年前后，然后是以信息的广播为主，那个时候成就了像新浪、网易这样的公司，他们都在做门户网站。他们做的事情就是编辑和发布新闻。 后来又到了互联网的（Web） 2.0时代，以社交为主，出现了各种各样的社交媒体，比如说国内最大的微信。海外有Facebook、twitter、Instagram等。 互联网的2.0时代主要是做社交的，现在是互联网的3.0时代。Web2.0时代公司收集了个人的数据和隐私，赚足了数据和财富。但是在互联网的3.0时代，个体要开始崛起，或者说叫个体的网络隐私的意识开始崛起。每个人都在想我的数据我要自己拿着，所以这个时候就是互联网的3.0时代。 我今天给大家分享的最主要有6大秘籍，如上图。树上结了两个果子，一个是写作，一个是营销。这是非常重要的两个秘籍，两个技能。这两个是输出。然后中间的树干是连接。第4个是阅读，第5个是英语，第6个是精力。秘籍4，5，6是输入，是根基。 我们先来看第一个秘籍，写作。写作这个事情，貌似很多人就说我不会写，我不知道写什么。如果你有疑惑，有这样的问题的话，恭喜你，你不是有这个问题的第一个人。我在开始写之前也是这样的，跟你有同样的困惑。我也不知道该写什么，我也不知道为什么要去写。我的博客从2012年开始的，这几年下来之后，我发现写作给我带来的收益太大了，真的是太大了。我赚钱超过一半的功劳是来自于我自己的写作（或者准确的说是我的博客）。我其实也没有那么勤奋，一周两周才能写出一篇来，然后发到我的博客上。但是我自己已经体会到了写作带来的好处，关键是你要持之以恒。 再讲讲为什么要进行写作。 我们刚才前面其实有讲到了，现在是叫互联网的3.0时代，但互联网从1.0到2.0再到3.0一步一步演进过来的。比如web 1.0的时候就是新闻的发布，在这个时代个人能做的很有限。但在互联网2.0时代的时候，社交网络发展起来了。在互联网的2.0时代的话，其实每一个人都可以来写作了，在1.0时代的时候，基本上还是门户网站有专业的编辑来写。互联网的2.0的时候，其实每个人都可以写，大家可以想一下你在社交媒体上每天你都会发多少是吧？对，你会经常发朋友圈，发微博，发各种文字。但这些东西很零碎，可以把这些内容都整理好，整理成文章发出来。 另外写作绝对是可以为你带来税后收入的，可以为你带来财富的，为什么这么说呢？因为现在的叫新一代的财富，全都是通过代码或者是媒体来完成了。 “The new generation’s fortunes are all made through code or media. ” 这句话你要深刻的去想一下，新一代的财富都是由代码或者是媒体来获得的，代码科技的力量，相信大家每个人都知道，比如说最大的搜索引擎Google。就是科技的力量。 但是媒体被人给忽略了。尤其现在是人人可以写作，每个人都可以做自媒体。这是为什么我们要去写，我们一定要去写。你哪怕是说一周写一篇，哪怕是说一个月写一篇没有关系，你一定是要写。从今天就开始你的写作，开始你的写作，开始你的写作。 接下来是写什么的问题。第一步写工作总结。每天你都在做什么工作。今天的工作做完之后，开始给自己留半个小时，想想今天的工作都做了什么，今天工作当中我写了哪些代码，然后我解决了哪些问题，把它写下来。只要不涉及到你的工作机密，商业秘密的，都可以写下来，并去把它发表出来。还有你今天比如说听了个什么广播，听了一句话很有感悟，然后看了一页书很有感触，写下来一定要写下来，写是你最好的一个思考的过程。 我特别要强调这一个秘籍，你如果get到了这一条。我相信5年后你会感谢我的。我已经看到了5年后你的成功。 接下来在哪写，其实现在的平台已经很多了。大家可以自己去看，根据你的行业，对每个人的行业其实都是什么都是不同的，你可能在技术行业的可能是有一些专门的技术的媒体，在可能运营行业产品行业。比如科技行业，可以在知乎上写；IT技术类的可以关注掘金；另外还有要做微信公众号，一定要做公众号。微信公众号是目前为止，最好的可以和粉丝互动的媒体平台，没有之一。 具体你用什么来写，用手写还是在手机上写，其实你都是可以自己来决定的。现在可以用语音来做输入。对这个都是可以的。对写的方式都是次要的，你甚至都可以直接在word里面就敲进去，敲进去之后然后再发布到平台上都可以。关键是说一定要写。 写作的话这里我要介绍一下石墨文档。大家可以看到石墨这个工具其实真的是非常的好用，石墨文档为什么这么说？尤其是当你不是一个人在写作的时候，其实我们这种叫在线的实时的编辑，用这个石墨文档非常好用。 在敏捷家社区里面，我们每周会有语音转文字的工作。我们每周会有一个分享，然后每周有语音转文字。语音转文字完之后，要对文字要进行修改和校正，我们要把口头禅去掉，以及整理文档的逻辑。这个时候我们需要多人来改一个文档。有三个小伙伴来一起改这一个文档，我们每个人修改其中的一段。最后再有人整体来做校对。所以这个时候如果你有多人实时修改文档的需求，这个石墨文档是再好用不过了。 另外石墨文档还有两个很隐藏的小功能。一个是历史版本。文档修改的每一个地方，都会有记录。这个地方是谁，改了什么。不满意修改还可以回退回去。然后另外还有一个小功能是版本。比如可以给文档打个版本的标签；版本可以是部门之间文档交接的标志，也可以是阶段性工作的存储。可以根据自己的需要和场景进行设置。所以这两个小功能保证你的文档在实时写的时候根本就不会丢。历史功能每隔几秒钟会自动保存。 第二个秘籍是营销，你一定要学会营销。然后首先今天的这次直播非常感谢石墨文档的邀请，来给大家做分享，所以这也是我自己做了一次营销。秘籍1是写文章，写文章之后一定要发表出去，发表到比如说你的个人的博客，或者是说你的社交媒体。现在视频也是越来越火。我也非常鼓励大家，比如说在抖音或者B站上面做直播。酒香还怕巷子深。不管你是内向还是外向性格，写作之后一定要让别人知道。并且是想办法让更多的人知道。 在2012年的时候我看过一本书，这本书是《brand you》。有关于个人品牌的，这是我读过的第一本关于个人品牌，并且写的非常棒的一本书。这本书里面介绍了个人如何去做品牌，以及做个人品牌的一些维度，都做了非常详尽的描述。并且书里面还给了你一些实打实的建议。比如说其中有一个建议就是，每一个人都应该要去做一个自己的个人博客。为什么要做一个个人博客呢？个人博客就是你在互联网上的房子。比如我的房子门牌号就是 bobjiang.com 。欢迎来我家做客，也欢迎给我的博客提建议和意见哈。想一下你所在的城市，你总是希望买一所房子。个人博客就是你在网上的一座房子，你可以是自己去装修它，装修成你想要的样子。 个人博客用什么平台都可以，关键是第一步先开始写作，然后找个平台来保存你的文字。一开始不要考虑太多用哪个平台。只要是平台是符合你的行业特点就可以。比如程序员更多可以去掘金社区，不要写小说去发表在掘金社区，这样就有点偏离了你的用户群体。 行动起来，在互联网上为自己安个家，不管是多么简陋，那就是你的家。 第三个秘籍是连接，这也是我10多年以来慢慢领悟出来的。 营销的最终目的不是说要达到多少粉丝。而是找到和你有共鸣的粉丝。我们比较难写出10万+的阅读的文章。但我们会坚持去写，坚持推广营销。因为只要你写了，你解决了某个特定的问题，就一定会有人看到的。只要你写的内容很干货，很能解决你自己的问题，那就会有人通过搜索引擎查到你的内容。因为你解决的问题，别人也有可能碰到同样的问题，所以别人就可以通过搜索引擎查到你。这个时候就能产生连接，要能连接找到你的这些小伙伴。注意收集和积累，你不管用什么样的工具去连接到能找到你的伙伴，那个工具是其次的，关键是要能这些人能连接上。可以用邮箱（比如做一个邮件列表），可以用微信群，可以用QQ群。工具都是为我们服务的。 和粉丝连接后，可以做什么，这个是关键的事情。 如上图右边，给大家介绍一个工具，乔哈里视窗。乔哈里视窗可以帮我们去认清自己。 更多资料参考百度百科 - https://baike.baidu.com/item/%E4%B9%94%E5%93%88%E9%87%8C%E8%A7%86%E7%AA%97⁄2501456 通过连接（社区）认识到不同的人，社区里面不同背景的人可以帮助你认识到自己的盲区，以及还可以帮助你打开自己的潜能。有的时候别人的一句话，可能一下子就点亮了你的世界。
2020/6/10
articleCard.readMore养成这个30秒的习惯，你将受益终生！
没有快速修复（也没有捷径）。我知道这是一个社会科学谜题，读了无数关于该主题的书籍和博客，并尝试了很多建议后发现大部分都没有用。因此，我不会对此轻描淡写。经过几个月的试验，我确信我所听到的，这是最简单的建议之一，也是最好的建议之一。 这个习惯不是从畅销书中来的，确实没有出版商会想要出版：即使是最雄辩的管理思想家也很难写一整本书来描述这个习惯。它也不是源于我们的数字过剩和不满世界。取而代之的是，这是一个19世纪出生的人，留给他的孙子的建议。 今天要采访的这个人是商业界的佼佼者，是我见过的最有趣的人之一。他帮助设计了家喻户晓的品牌。如今，只有当他感到自己有能力提供东西时，他才空降来帮助解决公司的危机。有时候，当他有足够的兴趣时，他会为《财富》 500强公司的首席执行官和政客们写演讲，他的话价值六位数。他特别擅长阅读，也擅长写作、小说。但是有一些只是为了好玩：完成后，他将其毁掉。他看不出出版或寻求宣传的意义。在他的朋友中，有一些地球上最有权势的人（从企业领导人到政治人物，演员和其他艺术名人）。 因此，当他分享他曾经收到的一些最佳建议时，我被迷住了。 如果您只做一件事，请执行此操作 当他的祖父将他拉到一边并告诉他以下内容时，他正处于少年时期，即将上高中。 在每次演讲、会议或任何重要的经验之后，请立即花30秒（不多也不少）写下最重要的观点。他的祖父说，如果您始终这样做，即使您只进行此操作而没有其他的行动。 我已经尝试了几个月。到目前为止，这是我发现的内容： 这不是记笔记： 不要以为记录了会议中的所有内容，就不会对30秒的总结（回顾）感到满意。尽量简短，但此练习与做笔记完全不同。这是解释、确定优先顺序和决策的行为。 这是艰苦的工作： 确定最重要的是非常消耗精力的。告诉自己，您已经掌握了所有重要内容，找到借口来避免这种短暂的心理冲刺（大脑进行了一个冲刺），这真是令人惊讶。 细节是一个陷阱： 但正是因为我们表面上经常捕获所有内容，从而避免了决定有价值的事情的辛苦工作，因此所有东西的价值都减少了。当然，卓越是做减法的艺术。30秒的回顾使您无法使用数量作为借口。 必须迅速采取行动： 如果等待几个小时，您可能会想起事实，但是却失去了细微差别。这决定了重要的事情。无论是某人声音中的语气，还是一个看似简单的建议引发许多其他建议的方式，还是某个通过评论而在您脑海中浮现的想法。 学会更好地聆听并提出更好的问题： 一旦养成了30秒回顾的习惯，无论听演讲还是参与讨论，它都会开始改变您的注意力方式。这就像学会在刺耳的声音中检测出简单的旋律一样。而且，随着您更加专注地聆听并提出更好的问题，这些问题会提示可行的答案，因此30秒钟的回顾变得更加有用。 可以为他人提供更多帮助： 缩短30秒的大部分原因在于观察对他人重要的事情。即使目的是帮助更好地管理将来的对话中的不同兴趣，它也可以帮助您了解其他人的需求，从而解决他们的问题。这并不令我感到惊讶：在采访那些慷慨交往的人的几个月中，我对有多少人有自己的无意识版本的30秒回顾感到震惊：专注于他们可以提供最大帮助的问题。 变得更容易和更有价值： 每次练习时，它都会变得更容易，更有用和更有趣。 我把这个习惯加入我的习惯清单中了，期待。 最后邀请小伙伴花30秒时间，想一下这篇文章你的最重要的收获是什么？ 附送我的习惯清单： 1. 冥想 2. Tabata 3. 知乎 4. 美国语文 5. 读书 6. 30秒反思 原文链接
2020/6/4
articleCard.readMore第14份年度敏捷状态报告（最新2020）
总结 您的组织是否在实践或规模化企业敏捷性？敏捷状态报告提供了世界上最全面的数据，用于基准化您的敏捷实践并计划下一轮扩展。 第14份年度敏捷状态报告基于全球1,100名IT和业务专业人员的经验。自成立以来，全球40,000名敏捷高管、从业人员和顾问分享了他们的见解，使敏捷状态报告成为同类报告中规模最大、运行时间最长的报告。继续阅读今年研究的一些关键发现。 文化仍然很重要 采用敏捷和扩展（规模化）敏捷的最高挑战仍然与组织文化有关。总体上组织对变革的抵制，管理支持和赞助不足以及与敏捷价值观不符的组织文化仍然是前五项挑战。今年，领导层参与不足的新选择也位列前五名。 分布式敏捷团队 - 新常态 尽管面对面的工作对于敏捷实践来说是理想的，但受访者表示组织正在支持分布式团队。由于越来越多的受访者表示他们的组织继续支持和鼓励跨地理边界和跨时区的团队合作，因此没有迹象表明共处一地的趋势有所增加。当前的全球健康危机可能也是一个转折点，这导致分布式团队的增加是“新常态”。 SAFe®是首选的规模化框架 规模化敏捷框架（SAFe®）仍然是受访者引用的最受欢迎的方法（并不是Bob喜欢的方法），比去年增长了5％，超过第二选择 Scrum@Scale 达到了19％。 “我们为SAFe®继续成为市场上最流行，最有效的方法而感到自豪。自Scaled Agile诞生以来，我们的核心信念一直很简单：更好的软件和系统使世界变得更加美好。在这种全球性大流行期间，可以肯定的是 - 在适当的环境下 - 远程敏捷团队可以提高生产力，并且企业可以通过应用SAFe®继续获得卓越的业务收益。” - SAFe®的创建者，Scaled Agile Inc.的首席方法专家Dean Leffingwell。 – 虽然SAFe是最受欢迎的规模化敏捷方法，但我（Bob）还是推荐可以学习考虑 LeSS 或 Scrum@Scale。 参考之前的对于SAFe篡改Scrum的博客 价值流管理的采用 价值流管理（VSM）是人员，流程和技术的组合，可通过从创意 到 企业软件交付流动来映射、优化、可视化、度量和管理业务价值流（以史诗，故事，工作项的形式）。 78％的受访者表示，他们的组织对VSM感兴趣，正在计划实施VSM，或者目前处于VSM实施的某个阶段。 有了这些回应，我们期望随着理解的增加和工具的更强大而能够统一“现金到现金”价值流的组织，越来越多的组织将接受VSM。 未来该何去何从 总体而言，调查结果表明，敏捷性仍主要限于开发、IT和运营。但是，关于业务敏捷性需要在组织的各个领域进行有效调整和协调的观点继续得到发展。明年，我们希望看到组织报告敏捷性进一步扩展到超出与构建、部署和维护软件相关的领域（译者注：即业务敏捷性，而不仅仅是IT领域）。 当敏捷扩展到整个组织时，每个人都会受益。 详细解读 以下Bob会每页进行详细的解读（如有解读偏差的地方，欢迎联络我修改） 封面如下 超过40,000名敏捷高管、从业人员和顾问参加了敏捷状态报告自成立以来的调查。（14年的总调查人数） 第14届年度敏捷状态调查提供了有关敏捷在企业不同领域中的应用以及价值流管理的见解。 查看结果时，您可能会发现一些熟悉的趋势，并发现上一年的调查中有一些值得注意的变化。 阅读并深入了解数字，以发现一些有趣的关联。 最新趋势 文化仍然很重要 采用敏捷和扩展（规模化）敏捷的最高挑战仍然与组织文化有关。总体上组织对变革的抵制，管理支持和赞助不足以及与敏捷价值观不符的组织文化仍然是前五项挑战。今年，领导层参与不足的新选择也位列前五名。 Scrum 和 SAFe® 仍然拔得头筹 Scrum 是实践最广泛的敏捷框架，至少有75％的受访者在实践 Scrum 或包括 Scrum 的混合体。 SAFe®仍然是首选的规模化敏捷框架，在35％的受访者中处于领先地位，比去年上升了5％。 敏捷鼓励适应性与可见性 今年，实施敏捷而得到改进的前两项能力是，管理优先级变化和项目可见性。继续进入前五名的其他改进能力是：业务与IT的一致性、团队士气、交付速度、上市时间和团队生产力。 敏捷又老了一年（又一年过去了） 与去年相比，三个调查结果均相差超过10%。 降低成本 今年26％的受访者采用敏捷的重要原因是 降低项目成本。这比第13份年度报告中的41％有所下降，但接近第12份年度报告中24％的答复。
2020/6/3
articleCard.readMore如何在各种文化背景下成功敏捷
7年前，我曾写过两篇著名的博文（和一本书）–《如何让你的文化有效》和《如何使您的文化与敏捷、看板和软件工艺一起工作》。在这篇博文中，你将学习到具体如何做到这点，及最新的建议和实践经验。文章的重点是如何在尊重东道国组织文化的同时，在文化泡泡中创造最大的成功。 如果你对发展组织文化感兴趣，请阅读《如何改变您的组织文化》一文。 文化是一种局部现象 首先要明白，在所有的组织中，文化是一种局部现象。有的组织有着更统一的文化，而有的组织文化则更多样化。大多数组织都有不同的文化或者不同部门有不同的工作方式。一个简单的例子可以说明这一点：产品开发部门的文化是关注创新和创造变化，而运营部门的文化是关注稳定和限制变化。这种典型的张力催生了DevOps领域。 意识到潜在的问题是文化的不匹配这一点很重要。在组织内存在这些差异是正常的，解决这些差异只有通过改变组织文化。现在，让我们关注如何处理文化差异。 文化泡泡：如何生存 在大多数的组织中，打造文化泡泡是他们成功实现敏捷和其它先进方法（如数字化，创新，精益等）最常采用的方式。大多数时候，在人们还没意识到的时候，这种变化就自动发生了。文化泡泡的形成始于一个领导者引入一种不同的工作方式，然后一种新的文化在这个组织内的引入和发展就产生了。在泡泡内部的一些新工作方式通常与组织内其它部门的工作方式有很大的不同，这种打造新文化的模式适用于组织的不同层级，比如团队，小组和部门等。 查看原文 不健康的文化泡泡模式 我注意到一个常见的模式是我们采取的行动在无意中降低文化泡泡的健康程度。以下是一些要避免的常见陷阱： 拒绝遵守流程或承担其它组织所需的工件。 不尊重其它群体，管理者决定以自己的方式工作。 期望、要求或鼓励组织的其它部门做出改变。 健康的文化泡泡模式 随着时间的推移，我收集了一套支持文化泡泡健康可持续发展的模式。具体如下： 与其它组织建立良好关系。标志我们处在一个健康发展的位置是我们在这个地方的表现”我们很好，你们也很好”。用另一个词表达就是尊重。 在你的气泡周边构建适配器，这样你可以向其它组织提供其所需的构件。敏捷中最常见的例子是如果他们需要一个项目计划，就给他们一个项目计划。 关注气泡的成长。专注于人员开发，以及他们交付组织结果的能力开发。 真正的秘诀是只关注在气泡内你所能控制的。诚然，会有来自外部的约束使事情进展缓慢，局限成功，但这是你无法控制的。 一个有助于理解的比喻是：将其它组织所有的非增值工作视为”税”。我们都要纳税，纳税只是生活的一部分。在组织中，我们需要为在组织中工作这项特权支付组织税。 如果你想了解更多详情，可阅读《如何构建文化泡泡》和《构建文化适配器避免敏捷失败》。 如何发展文化泡泡 人们通常对改变他们的泡泡之外的东西感兴趣，这有两方面的原因。第一是他们对自己的工作方式感兴趣，想让别人也效仿；第二是其它组织的不同文化对他们适配器的运作是一种负担。 我们看看你能控制什么？ 在文化泡泡外的：不能 在文化泡泡内的：能 专注于打造一个繁荣的泡泡 秘诀是专注在泡泡内取得成功。积极热情，交付产品，得到客户的喜爱，然后令他人惊叹。 这是完全在你的掌控之中的。 以下是未来将会发生的事： 公司其它部门可能会来效仿。如果他们需要帮助，就给他们帮助。这就是敏捷–以拉动为基础，等待其他人来找你。 泡泡的领导者将得到提拔，然后泡泡就会因这个领导者的影响力增加而扩大。 这是一个证实的模式。我从世界各地听到了很多这样的例子。那些从我的领导力培训中毕业的人都说他们成功运用了这些原则。 Woody关于如何更快传播的诀窍 Mob编程（Mob Programming）和”不用估算（No Estimates）”思想的先驱者Woody Zuill分享了一个让泡泡内的文化更快传播的诀窍来帮助大家。该诀窍是，我们通常是专注于自己的成功，即使周边的人正面临困难（这实际上是默认的Scrum流程）。而Woody是这样想的：”嘿，其他人和其他部门正在挣扎斗争，为什么我们不帮助他们？”与其要求别人改变他们的工作方式，不如主动帮忙他们取得成功。猜猜通常这样做会发生什么？当其它人注意到你们很快乐，在泡泡内很投入，他们便会好奇你们在做什么，是怎么做的，然后他们也会想要那么做。 【审校注】主动帮助他人解决困难。 总结：如何让你的文化有效 让我们在此回顾关键内容： 文化是一种局部现象 在泡泡内发展一种本地文化 围绕泡泡构建适配器以保持健康状态 怀着感恩的心缴纳组织”税” 专注于自己的成功 发展需要时间 相关文献 原文链接 我的敏捷文化转型之旅 https://agilitrix.com/2015/06/my-journey-agile-culture-transformation/ 企业敏捷还是敏捷型企业 https://agilitrix.com/2015/03/enterprise-agile-agile-enterprise/ 敏捷失败与企业文化 https://agilitrix.com/2011/12/agile-failure-and-corporate-culture/ 作者：Michael Sahota 译者：郭佳艺
2020/5/22
articleCard.readMore如何改变组织文化
您将学习如何改变您的组织文化。是的，如何改变您的组织文化。这需要努力和专注，并且这是可能的。我已经做到了，还有全球的领导者也已经应用了同样的信息来改变他们的文化。以下内容是已证实的步骤的概述，也包括支持变革的资源。 一、渴望成长 文化变革的起点是渴望——一种创造变革的强大动力。没有什么比渴望驱使更容易获得成功，发现渴望这就是开始。任何对改变文化感兴趣的人都需要深入了解是什么在驱动他们，并确保他们有动力去做所需的工作。 我以前很赞同科特的”紧迫感”，甚至提倡这一点。现在不再这样做了。事实证明，紧迫感与恐惧和较低的心理安全水平有关。这抑制了个人和组织的成长，基于这个关键原因，”渴望”是一个更好的选择。 强烈的增长渴望是必不可少的 在过去几十年里保持增长的组织将改进视为日常工作的一部分。他们投资于增长，因为这很重要。这是正确的做法，而并不是因为增长很紧急。 二、了解现有的文化 下一步是了解你现有的文化。但是什么是文化呢?我们可以把它定义为”我们是如何做事的”。我尝试了许多文化模型，并推荐了两个得到验证的、简单的、影响力方面的模型。你可以把它们结合在一起来诊断你的文化和成长的方向。 Sahota文化模型通过识别形成文化的相互关联的元素，提供了对文化的清晰理解。它还强调了不仅要关注结构，还要关注系统的意识(或思维)。我们经常陷入关注结构(尤其是过程)的陷阱，而不是关注人和他们如何一起工作。这个模型提醒我们，真正重要的是意识(或心态)，是人，而不是结构或过程。 另一个非常强大的模型是Laloux文化模型的修改版本。它可以用来评估组织现在的位置。它还有助于激发选择一种更高效工作方式的愿望，例如绿色（它象征着成长、和谐、新鲜和丰饶）或蓝绿色（它是一种充满活力的颜色，也代表着开放的交流和清晰的思想）。使用该模型的一个关键原因是，它有大量的案例和研究来支持高效工作的主张。它也与许多其他文化和行为的模型和理论的观点一致，如道格拉斯-麦格雷戈（美国心理学家）的X - Y理论。 三、创造一个愿景 下一步是看案例研究和你想要成为的公司的例子。这里有很多很棒的资源，比如《重塑组织》这本书，或者《通往高效组织文化的各种途径》一文。 使用这些作为灵感是个好主意。我们的目标是创造一个符合变革愿景的”地平线之星”。不要尝试复制结构，复制只是简单地为您提供没有文化转变的结构。 找到自己的路径 这里的秘诀是找到符合自己的路径。选择路径主要取决于两件事：1.组织中的现有情况。我们只能从我们所处的地方成长和发展。2.人们共同创造新未来的愿望。愿景可能只是由最高领导层创建，或者他们可以与整个组织的人共同创建。 四、本土文化的发展 一个常见的误解是文化变革是针对整个组织的。重要的是要了解在大多数组织中，文化因团队、部门和地域而异。它与每位经理一样独特，所以请记住这个关键点： 文化是一种当地(local)现象 由于文化是一种本地现象，这意味着可以在组织内部进行地域化修正。最常见的方式是文化泡沫。当我们这样做时，文化差异会带来张力和挑战。 减轻紧张局势的关键思想是建立文化适配器。在泡沫内部和泡沫外部将有不同的工作方式和不同的值。适配器的想法是通过在工作方式之间构建适配器来减少与组织其他部分的冲突。这是创造可持续文化泡沫的关键模式。 五、领导先行 文化主要反映了领导力。在组织的底层发生的事情是组织顶层发生的事情的分形。（感谢Glenda Eoyang的这种智慧）。众所周知，团队的表现是他们经理的直接反映 - 这一点在近20年前通过盖洛普12个”参与”问题的实证研究得到了证实。 文化变革不可委托 文化变革的方法是让领导者改变他们与人和组织系统互动的方式。这里的一个关键概念是组织行为遵循领导行为。一种新的组织行为工作方式要求领导者以新的工作方式行事。如此成功的转型需要领导者先行！ 六、领导力成长是必须的 我职业生涯中的一个重要教训是，领导者是增长极限。我注意到，要创建高绩效的组织系统，领导者需要自我培养。他们需要成长为我们在高性能环境中看到的那种领导者。这意味着要培养信任，安全和建立连接的内在工作。作为领导者，我们需要控制自我，以便我们能够培养我们周围的领导者。 这不是为胆小的人准备的。我们谈论的不仅仅是作为领导者，而是作为人来发展我们自己。和你一样，我也在旅途中。我创建了4A的自主意识领导模式来收集我一直在使用的逐步成长的方法。它是一个强大的工具，可以帮助我们重新审视那些阻止我们成为希望成为的领导者的无意识行为。我们深受社会的制约，做出了与高绩效相矛盾的行为。专注和努力是改变我们习惯和无意识行为的必要条件。 学习型组织是每个人成长的渠道 还记得步骤1中对组织发展的渴望吗？这是你需要它的地方。个人成长需要强大的努力来保持。 这是改变文化的秘诀：我们所需要做的就是改变我们的行为，文化将随之而来。 七、这是一次旅程 以上步骤对于组织中的文化更改来说是充分且必要的。这里共享的是文化变革的关键起始要素。当然，还有更多关于如何完成这里列出的步骤的细节，甚至更多关于支持旅程的细节。 八、不管你的角色是什么，你都可以这样做 我培训过的高管、经理和教练都成功地运用了我在这里分享的东西。我们都是领导者。我们可能是领导者，因为人们向我们汇报，或者我们有更多的资历或专业知识。我们也可以成为一个领导者，因为我们选择如何去展现。 九、你可以马上动手 不管你的角色是什么，你都可以选择以未来公司领导者的方式展现自己。你完全可以控制自己的行为。 你不需要许可、预算或权威 您不需要许可、预算或权威就可以开始以模拟高性能行为的方式行事。我们所有人都可以立即改变我们本地的文化。这里唯一的限制是你对自我发展的渴望和投资。 这对我们作为领导者来说是一个巨大的转变。当然，我们仍然需要支持身边人的发展，这样我们才有各级领导。但是，这对于我们成长来说是次要的，因为我们要充分塑造我们希望创造的未来组织文化/组织所需要的那种组织领导者。 十、总结 以下是改变你的文化的六个关键步骤: 渴望成长。 了解现有的文化。 创建愿景。 本土文化发展。 领导先行。 领导力成长。 这里有一些重要的建议要记住: 这是一段旅程。 无论你的角色是什么，你都可以这么做。 你可以立即实施。 你不需要许可、预算或权威。 作者：Michael K Sahota 译者：年志君 审校：Bob Jiang 查看原文 英文原文
2020/5/21
articleCard.readMore团队与领导力健康检查 | 体检表
查看原文 在此博客文章中，我想分享一个强大的工具Leadership Health Check。这将帮助您的管理团队变得更强大，并为积极的服务型领导团队揭示改进机会，从而更好地赋能您所支持的敏捷团队。 首先，让我们从头开始。 在敏捷教练的工具箱中，我最喜欢的一项练习是在Spotify工作期间学到的 Squad Health Check （中文版：https://www.bobjiang.com/posts/blog/sqad_health_check_model.html） 。这是一种以回顾的形式进行自我评估的研讨会。在会上，团队表达自己在各种主题上的感受，例如协作，交付的价值，影响力，获得组织的支持等。结果会生成对团队和领导力的洞见及改进措施。我喜欢这个工具，因为它是加强自组织，组织文化和持续学习的非常棒的工具。 一年多以前， 我和Spotify 的一位同事Georgiana Laura Levinta为我们的tribe创建了领导力健康检查（tribe是Spotify的半自治部门，由4-8个团队组成，有一组专门的leader和经理）（更多有关tribe可以参考 https://www.bobjiang.com/posts/blog/scaling-agile-spotify-with-tribes-squads-chapters-guilds.html） 。 我和Geo受到了Squad Health Check的启发，采用这种做法帮助tribe的管理者自我评估他们向tribe内的squad提供积极支持的领导能力，并讨论他们如何作为一个团队进行改进，以提供更好的支持。 从那时起，我和Casumo客户一起基于他们的背景、文化和信仰采用了这一方法。我们已经在公司的领导团队以及tribe级别（半自治部门）实践了几次，获得了巨大的成功和价值。我相信 Team Health Check和 Leadership Health Check都非常强大；因此，我想将它们推荐到更广泛的敏捷社区，希望更多的组织会发现它们的价值，或者至少受到他们的启发，然后进行完全不同的尝试。 如果您不想了解团队和领导力健康检查背后的起源和思考，而只是来这里下载研讨会材料，请关注本公众号回复”检查表”获取下载地址。 团队健康度检查表 （Spotify的 Suard Health Check） 起源 Spotify的Suard Health Check的第一个版本看起来与今天的版本有很大不同。它提出了诸如”您有产品负责人PO吗？”，”您有敏捷教练的支持吗？”和”发布容易吗？” 之类的问题。随着这些组织上的痛点（例如，并非所有的团队都有PO）逐渐消失，该调查逐渐发展为更加关注自组织，团队合作，可持续流程和任务明确性（见右侧示例）。 这种形式在Spotify内部迅速传播开来，越来越多的团队和tribe’使用这个。如今，这已成为许多组织中根深蒂固的习惯。团队每年进行两次到四次check。当每个tribe根据其背景和需求采用它并与其他tribe共享其版本时，该工具得到不断发展。 The Team Health Check 我在这篇博客文章中分享的 Team Health Check的灵感来自Spotify的 Squad Health Check。通过与其他客户的合作，我对其进行了改进，使其更加通用。 现在对各种主题和评论的阐述，试图嵌入呈现一些著作的思考和研究：如 Christopher Avery的Teamwork is an Individual Skill ， J. Richard Hackman的 Leading Teams ，Daniel H. Pink,的 Drive ， Stanley McChrystal的 Team of Teams ， Patrick Lencioni的 Google’s Aristotle Project和The Five Dysfunctions of a Team ，还有甚多其他书籍和敏捷领袖的思想研究。
2020/5/20
articleCard.readMore如何在敏捷转型中克服阻力 – 邀请的力量
几乎所有的敏捷转型项目都遇到了来自经理（管理层）、员工或其他部门等的阻力。在这篇文章中，我们将解释为什么你会遇到阻力，以及如何消除或减少这些阻力。 为什么我们会遇到敏捷转型的阻力？这难道不是为了改善人们的工作环境，让他们更有效率吗？让我们假设敏捷是一个好主意。那么，我们将它引入组织的方式有什么问题呢？ 一、推送产生阻力 “像往常一样转变”的关键挑战是，变革被推到人们身上，而他们没有参与决策。这样他们常常会拒绝变革。 二、推送对你有什么影响？ 有很多方法可以产生阻力，这就是推的变化。当你读到下面的文字时，想想当某个当权者对你做出这样的行为时，你的感受： 告诉 销售 迫使f 说服 对大多数人来说，这些话会感到不舒服。 我们不喜欢别人告诉我们该做什么。我们不喜欢有人强迫我们做某些事。我们不喜欢别人试图向我们推销什么或说服我们相信他们的观点。当这些事情发生在我们身上时，我们会自然地抗拒。 三、敏捷转型反模式 结果是每个人的反应都和我们一样。我们推得越多，就会产生越强的阻力。下面是一些关键的反模式，可以帮助理解我们是如何通过创建阻力来推动失败的敏捷转型： 授权整个组织/部门变更。很多人认为这是一个巨大的成功：”欢呼，现在每个人都必须做敏捷”。但是，这场胜利是空洞的和短暂的，因为很快变成了一个普遍的”货物崇拜（19到20世纪中期在大洋州的许多土著社会中兴起的一种文化复兴运动）敏捷”案例，许多人在做这些事，但除了名字之外，什么都没有真正改变。 敏捷福音。在我们的领导力培训中，我仍然遇到很多人，他们认为自己是敏捷福音的传道者。积极的方面是想把事情做得更好。消极或破坏性的方面是推销和说服。这造成的阻力和伤害通常超过积极的。我所见过的每一个成功的变革都不仅仅是敏捷。 敏捷指标(敏捷警察)。另一种出于善意的方法，以衡量”敏捷”团队的程度，并为他们设定了”更敏捷”的目标，在实践中犯了严重的错误。这很清楚地告诉人们，做敏捷比敏捷本身更重要。如果你想在这里取得成功或者获得奖金，你就必须采用敏捷。这表明这个过程比人更重要——与敏捷正好相反。 四、敏捷是关于拉动的 深入到敏捷真正的核心——敏捷不是基于推送，而是基于拉动。与精益一样，Scrum团队会拉动下一个冲刺（Sprint）中完成的工作。看板团队在准备就绪时拉动。 五、推送无法创建拉取 我们如何用推送的方法来创造一个支持”拉动”的环境呢？这没有任何意义。有证据表明，使用推送是行不通的。当然，我们也许能创造出一些表面上看起来起作用的东西。然而，对于那些拉动工作所需的积极，敬业的人才，实际上，需要一些不同的东西来实现行动的深刻转变。 六、什么是拉动？ 与推送列表类似，我们可以创建相反的拉动列表。 当您阅读以下单词时，请思考他们的感受： 邀请 倾听 激发 共同创造 对大多数人来说，这些话都是积极的。这就是我们想要在组织中创造的促进成功的效果。 我们喜欢有选择的自由。我们喜欢别人邀请我们，这对我们来说是可选的。所以我们可以自己决定。我们喜欢别人听我们说我们想要什么。当我们为某事受到鼓舞和兴奋时，感觉真的很好。我们喜欢参与那些影响我们的决策。你能想象当人们有这样的感觉时，你的改变计划有多有效吗？ 七、拉动成功模式 看我们做错了什么要比看我们做对了什么容易得多。让我们看看使用拉动的一些关键成功模式。如果您不熟悉这些，或者对此持怀疑态度，我们将邀请您进行实验来尝试它们。 倾听。大多数人想要成功。大多数团队都想成功。一个巨大的挑战是，我们经常不会花时间去倾听他们想要什么和他们的想法。花点时间去倾听他们想要什么。满足他们想要的东西。在告诉他们你的想法或想要什么之前，先给他们列出清单，这样你会得到更多。 去有活力的地方。创造广泛成功的方法是取得小的成功，并在此基础上再接再厉。与那些现在真正需要帮助的人或团队合作，给他们想要的帮助(倾听)，并帮助他们成功。过一段时间，其他人或团队可能准备好了，或者他们可能会看到正在发生的事情。 共同创建解决方案。敏捷是关于协作的，对吗？如果我们遵循敏捷方法，我们是否会与人们就转型本身进行合作，这是不是很明显？我喜欢共同创造这个术语，因为它让受变革影响的人参与到变革当中。这类似于精益变革和开放空间敏捷所倡导的方法。我所看到的工作的一个不同之处在于管理者和主管们也需要与员工一起参与这一过程。当然，这通常需要对管理人员进行培训，以便他们学会如何以帮助和不伤害的方式放弃权力。 八、推与拉 下面的图片有助于对比我们在敏捷转型计划中与员工和团队合作时的选择。 查看原文 将我们的思维模式转变为这种新的工作方式（敏捷）的一个关键挑战是，这让人感到不舒服。特别是，我们通常在”拉动”这个模式的技能水平很低。真的要花点时间看看你是如何不经意地用”推”的模式来制造阻力的。一旦我们明白了”推”这个模式真的不起作用，我们就有勇气成为一个使用”拉动”模式操作的新手。关于以一种友好的（拉动）的方式运作还有很多要说的，所以如果你认为这不是全部，你是正确的。 九、敏捷是关于人的 敏捷的核心是”个体和互动高于流程与工具”。敏捷的核心成功模式是，当我们更多地关注人而不是流程时，成功就会到来。大多数敏捷的转型都是本末倒置，把重点放在了流程上。通常的推送行为清楚地表明，大多数”敏捷转型”实际上根本与敏捷无关。 十、敏捷的第2次浪潮 我们需要对敏捷进行根本性的反思，以克服当今的挑战。我们称之为敏捷的第2次浪潮。这意味着把人放在首位，邀请变革。放弃破坏性的推送行为，这不是要让所有人这样做。这是关于我们的领导者自己开始模拟我们想要在其他人身上看到的行为。你准备好加入敏捷的第2次浪潮了吗？ 十一、明天做什么 注意其他人使用推送行为的方式以及它对你的影响。 注意您使用推送行为的地点以及它如何产生阻力。 增加”敏捷/拉动”活动，看看人们如何反应。 译者：年志君 审校：Bob Jiang 英文原文
2020/5/20
articleCard.readMoreCSM Training 记录、收获与心得
转自学员Leon的总结 5.16 ~ 5.17 参加了捷行与 Bob 老师组织的 CSM 双 CST 讲师认证课程，收获远超出预期。 我是编程出身，11 年开始，一直从事互联网行业，17 年正式使用 Scrum 作为敏捷开发框架，也开始接触 Agile，过程中慢慢学习、摸索和运用 XP、TDD、BDD、DDD 等思想和方法，从 Coding 到 Team Leader（兼职 Scrum Master），到现在全职做 Scrum Master。 本以为自己”经验丰富”，对 Scrum 框架的理解”非常透彻”，想通过 CSM 认证后，向 A-CSM 进阶。然而两天的课程下来，还是给我带来不少收获。 两位老师都有各自的风格，Jim 老师有国际软件公司的经验，Bob 老师有一线互联网公司的经验，两位老师轮流教学，虽然部分内容会重合，但是在不同的场景与角度下，总能让人 ~ Aha / Wow / Ya。 记录 因为疫情的原因，我们两天的认证课是通过 Zoom 在线学习，我们小组在共创的过程中，还用到了石墨和 Teambition。 在线的好处就是打破了地域的边界，能和不同地方的学员一起交流，以北上广深居多，学员们来自各行各业，除了互联网行业，还有制造业、传媒业，金融业等，有开发、技术管理、项目管理、咨询师、数据分析师、产品经理（噢！为什么不参加 CSPO）等。虽然大家对 Scrum 的经验各有不同，但都有强烈的好奇心和学习的热情，哈哈。 在线的坏处就是互动不方便，有时候会受网络波动的影响，当然两位老师设计了不少互动的环节，通过 warm-up、在线画画、分组交流、小组课堂练习、课堂提问等，让大家保持互动与反馈，当网络抖动的时候，也会停顿休息下，保证课程的质量。 课堂中老师会通过画布，边讲边画，让课堂变得有趣，从而抓住大家的注意力，很赞。 两天的学习内容很多，节奏也很紧凑，从 Agile 的思想，到 Scrum 的 3355、PBI、DoD、Kanban 等等，经过这次体系化的学习，让我把所积累的知识再串联与梳理一遍，特别是 Day 2 下午的课堂练习，模拟了 3 个 Sprint，让我们每个人都 Inspect 自己的学习成果，十分受益。
2020/5/19
articleCard.readMoreScrum培训感想
研究生期间，我在北京一家咨询公司做过三个月的实习生。当时负责的项目采用了敏捷方法进行项目管理，这让我对于敏捷有了一个粗略的认识。回到学校后，我总会在课堂中以及与项目小组成员讨论时，或多或少会听到敏捷以及Scrum的概念。所以我慢慢的认为敏捷项目管理一定是未来信息系统项目管理的发展方向，尤其是在这个科技日新月异不确定性极强的时代。 回到中国之后，我的第一个项目就是政府的智慧城市相关项目，这个项目真的完全让我震惊了，因为一个几百万的项目所聘用的团队连基本的项目管理都没有。在这样的团队中工作，个人的感觉就是被动、混乱与疲惫。所以我想学习最新的项目管理方法，来改进我们团队的工作方式同时也提高自己的工作效率。于是在朋友的推荐下，我就来参加 Bob Jiang 和 Jim Wang的Scrum Master 的培训。两天的培训让我顺利的拿到了CSM认证，在我看来，这次培训是非常不错的。 首先，Bob和Jim老师都是具备丰富的项目经验以及教学经验，在课堂上老师们会主动的分享自己的案例与实践，让同学们更好的掌握Scrum。同时，他们注重理论与实践的结合，在每个知识点讲解之后都会安排小组练习，确保同学们都能充分的了解知识点。 除此之外，课堂练习的设计也是非常精妙。课堂中让我印象最深刻的就是小组成员们一起制作视频的课堂练习。这对于每一个小组都是一个艰难的任务，尤其是每个Sprint只有10分钟的情况下。在这样极端的情况下，我们全部小组成员立刻就拿出自己的十二分精神，快速的进行Scrum中的各个环节：计划、执行、评审、总结、再计划。在一次次不断地迭代中，最终我们终于完成了在B站上传视频的任务，我也有幸成为了一名Up主，这真是人生中不可多得的一段经历。 两天的课程过得非常快，培训结束之后，我对Scrum有了更深刻更完善的理解。这种理解不仅仅是理论层面，更多的是实践层面。但是如果你要问我，这个培训之后，你的痛点有马上解决吗？这个我不能马上给出反馈，但是可以肯定的是，我已将敏捷的思想牢记于心，在日常的工作中会用敏捷的方法来约束自己，小步快跑，快速实现团队和自身能力的提升。 来自学员 Huan CSM信息大全 想要约 CSM 课程，扫码 –
2020/5/19
articleCard.readMore如何讲好故事
我最近在申请EHF - 新西兰的创业移民项目，在写申请材料的过程当中，我深刻意识到了讲故事的重要性！ 下面跟大家分享一下我的例子。这里特别感谢我的好朋友丹尼尔(Daniel Bar)。以下的第2个版本就是我的好朋友丹尼尔帮我做的例子，受到这个讲故事手法的启发，我才写了这篇博客，也希望把好东西分享给有需要的人。 原来的故事 2019年我去尼泊尔和孟加拉交付了两次培训课程，还分别在这两个国家进行了两次敏捷演讲的分享，通过这个事情我连接了东南亚的当地敏捷社区。 怎么样读了上面的文字，你有什么感受呢？ 改进版本的故事 中国是一个快速发展的国家，在中国敏捷已经慢慢得到普及。但与此同时我意识到东南亚的很多国家，也急需要敏捷来帮助他们改变工作与生活的平衡，改变他们的行业，改变他们的公司。我相信敏捷一定可以帮助他们得到更好的生活，也一定可以帮助他们改善现有的工作状况。所以2019年我受到尼泊尔和孟加拉敏捷社区的邀请去交付了两次演讲的分享，同时也做了两次培训课程，为当地人民带去了目前全球最新的思想和知识。 这个版本呢，读完之后有什么感受？ 很明显，第2个版本更像是一个故事，从讲我自己的价值观，再到讲我的心路历程。这样更容易打动读者的心，更容易让人相信你说的话。而第1个版本只是描述了一个事实，可能有人就会问那又怎么样？与我何干？ 所以讲故事的核心：要和自己的价值观连接到一起 总结与反思 - 黄金圆环 大家还记得西蒙西涅克的黄金圆环吗？ 讲故事也遵循同样的黄金圆环原则。 如上图所示，黑色箭头是第一个版本的故事，主要讲了事实（what）。 如果只是讲事实，这就是属于什么(what)的层面。只是告诉了别人一个事实又怎么样呢。 多数人讲故事是这个套路，难以打动人。 而如果我们从为什么（why）开始讲（如上图红色箭头）。则会完全不一样。比如为什么会去做这个事情，我的动机是什么？然后再讲怎么做的，得到了什么结果，这样的故事会更加的强大，更加的具有感染力。（这里面也离不开what，具体的数字和结果） 所以下次你再讲故事的时候，要不要也试一试呢，先讲出你的动机，你的价值观，为什么会去做这件事情。 把这些交代清楚之后再来描述你要讲的故事，看看会有什么样的效果。
2020/5/19
articleCard.readMoreScrum未完待续
把每件事都当作一个项目来推进，是我之前参加的一个线上课程的结束语，这句话在软件行业体现的尤为突出。过去我们关心的是如果快速的交付需求，很少考虑如何快速应对不断变化的需求。 还记得一开始学习软件工程的时候还只有瀑布模型、需求分析、系统设计等这些传统软件工程内容，但是经过十几年的发展，在软件项目中，敏捷开发、持续集成、微服务等这些新兴内容已经开始在软件项目中占据越来越重要的位置。从19年开始我通过网上的资料知道了敏捷知道了Scrum，也开始逐步的在现有项目中引入一些敏捷的实践，一开始我们只是通过几种项目管理工具帮助团队同步项目的进度，一段时间以后项目管理工具就变成了日报填写工具，大家每天都在上面填写这一天的工作和明天的工作计划，再后来项目没有看到敏捷带来的好处，敏捷推广也就无疾而终了。现在看来我们当时只是拿着别人用过的一部分实践复制到了我们的项目中，距离真正的敏捷还差得远。 2020年年初通过朋友介绍参加了敏捷家的几次线上分享，通过嘉宾的分享逐渐的对敏捷和Scrum有了更多的了解，也逐渐有了想要更加深入学习Scrum的想法，之后就顺利成章的报名参加了Bob的CSM课程。 从5月16到5月17两天的课程，BoB从敏捷的概念，Scrum的概念、原理、价值观再到我们常说的“3355”一步步的进行了讲解。每个概念讲解结束后都会安排小组进行讨论分享，在无形中我们每个小组通过讨论进行了多轮交付，每次交付其实都是对于Scrum不同方面的实践。相比与枯燥的照本宣科，这样的教学模式印象更加深刻，也在一定程度上解决了远程教学注意力分散的弊端。在第二天的课程中Bob介绍了在其他公司的Scrum实践，帮助我们在课程结束之后尽快的将所学引入到公司项目中。整个学习过程紧张而有节奏，回顾整个课程学习我感触最深的有以下几点： 一是对于DoD的定义，以及DoD和AC之间的区别。这些是之前项目迭代过程中一直忽略的地方，没有定义好DoD就没办法进行高质量的交付。 二是课程中介绍的什么项目适合开展Scrum，Scrum不是适合于所有项目，要有选择的机型Scrum推广。 三是如何对User Story进行切分，每个Story多长时间最为合适。 课程的结束只是代表着对于Scrum的初步了解，距离真正的CSM还有很长的路要走，只有在项目中实际应用Scrum才能更加熟悉每个流程环节的作用和价值。Scrum未完待续。 来自学员 Qihui CSM信息大全 想要约 CSM 课程，扫码 –
2020/5/18
articleCard.readMore再次强调完成的定义（DoD）
之前我写过一篇文章，关于敏捷坑人系列不清晰的完成，在这篇文章当中，描述了完整的定义和验收标准之间的区别，但是最近的课程当中依然有不少小伙伴在提问关于完成的定义，那今天的来说一下，为什么我们要设定完成的定义（即其重要性） 完成？！ 在工作当中往往我们会说这个事情我完成了。当我们说完成的时候，每个人对于这个完成是有不同的定义。比如PO认为完成是需要包含完成编码，提交到代码库，完成单元测试，完成集成测试，完成功能测试，等等一系列的测试。 而开发小伙伴可能认为完成只包含代码，以及在自己的电脑上测试，没有问题就算是完成了。 那这两个完成之间是有很大的一个差距，而这个往往会造成大家对于完成的理解误区，及同时也会造成沟通上的冲突。 完成的定义 Definition of Done 在这个背景下，团队需要对于完成有一个统一的认识。这个完成会包含很多不同的层面及不同的步骤。 举例说，如果说一个产品功能完成了会包含什么？如果开发完成了会包括什么，如果测试完成会包括什么，这是不同的层面。但是在Scrum指南中完成默认是指的产品完成。 完成的定义就像是一道门槛 团队一起设好了门槛，能跳过去的功能（PBI）就是完成了，跳不过去的，就是没完成。没有完成一半或者完成90%这样的概念。 所以对于这道门槛我们要设多高，这个是看团队对于自己的要求是多少，以及团队对质量的要求是多少，这是非常重要的一一个概念 验收标准 Acceptance Criteria (AC) 验收标准更像是PBI（功能）自身的一部分，或者用户故事的一部分。验收标准和用户故事是完整的整体，且不可拆分的。 也就是我们在梳理用户故事的时候，要同时梳理出这个用户故事的验收标准。 举个例子，比如登录功能，如何这个登录功能才算是完成呢？最简单的用户名密码正确就登录成功，用户名密码错误返回错误原因。这是最简单的两个验收标准。这两个验收标准就是用户故事的一部分。 总结 完成的定义和验收标准相同点 需要团队和产品负责人共同协商确定 代表质量，不过是不同的范围 不断迭代和不断演进 完成的定义和验收标准不同点 完成的定义是关卡，对所有的PBI（功能）适用；而验收标准是PBI（功能）的一部分，仅对当前一个PBI适用 完成的定义是内部质量；而验收标准是外部质量 完成的定义一般在团队组建时建立；而验收标准在梳理PBI时提出 完成的定义一般以季度为单位进行扩展；而验收标准则在产品待办列表梳理会上进行澄清与更新 完成的定义一般作为团队工作协议的一部分；而验收标准则可以转换为测试用例（或拆分为新的产品待办列表条目） 关于用户故事和产品待办列表，在我之前的博客当中也已经有详细描述，大家可以参考。
2020/5/18
articleCard.readMore在敏捷实践中加速成长 | 敏捷家分享009
内容来源：敏捷+社区线上直播009期，《在敏捷实践中加速成长》分享实录 分享者：平安壹钱包杨大鹏 关注本公众号回复”平安”即可获取本次分享的视频回放、下载PPT 平安集团是国内少有的，具备成体系的敏捷教练队伍的企业，从上到下拥有很好的敏捷土壤。再介绍一下我自己，我有十几年的工作经验，最初几年是做程序员，后来转向了项目管理和技术团队的管理，长期服务于外资银行和金融互联网的企业，我曾经在日本生活过很多年，非常熟悉传统的软件研发流程，也算是比较成功的 it项目管理者。我可以非常准确的挖掘客户需求，管控项目成本，管理团队，把成果物非常高品质的交付给客户。 但是后来我发现了一个问题，我不知道我交付的成果物能否为客户带来价值，项目结束结项以后，团队可能就会解散重组，我也没有办法持续地去帮助团队的成长。针对这两点我曾经非常的苦恼，后来就开始逐步学习敏捷的理论，毫不回头的走向了敏捷实践。 今天我和大家分享两部分内容，第一部分是在敏捷实践里，个人应该树立怎样的目标。第二部分我会用我自己的一个比较接地气的案例，来分享针对团队级别的敏捷实践，我怎样去具体解决一些常见的难点问题。用这个案例来分享我的思路和认知，希望能给大家带来一些参考。也希望能够帮大家少走一些弯路。 第一部分，我们现在是身处复杂的互联网时代，非常复杂，也被称为乌卡时代，典型的案例小黄车ofo，几年的时间里跌宕起伏，让人叹为观止。 查看原文获取更多材料和音频
2020/5/17
articleCard.readMore引导式互动交流，快速沉浸学习|参加Bob线上CSM课程总结
4月11-12日参加了BoB Jiang 老师两天的CSM（Certified Scrum Master）敏捷教练培训课程，非常感谢BoB老师带来的精彩课程，收获满满！ 敏捷开发是最近几年在软件和互联网产品开发领域日渐普及的开发模式，在之前的工作中，或多或少都应用到了一些具体的实践，比如每日站会、冲刺（迭代）等，或多或少在项目管理中都会有所收益。通过参加BoB老师的两天培训课，更加系统梳理和理解了敏捷框架Scrum的核心内容。 BoB老师语言幽默，两天的课程内容知识量非常大，且包含大量引导式互动交流实践环节，很容易在小组的互动实践中进入角色，深入理解并应用相关的知识技能，每个实践环节的总结部分，都是画龙点睛，对所学内容进行阶段性复盘，在最后一天的培训中通过大量实际企业中的敏捷实施案例，通过提问集中解答方式，一一解答大家在实际实践中的疑惑，提供大量宝贵参考案例。 虽然由于疫情影响，两天的线下课程改为了线上课程，但是内容丝毫没有打折扣，反而在互动交流环境以及小组讨论环节有更好的体验，Scrum 框架的核心：3355（三个角色、三个工件、五个活动、五个价值观）通过BoB老师精心设计的小视频、手写板、小组互动、小型敏捷项目实践、实际实施过程中典型问题的分析讲解等，演绎得生动形象，无论是第一次接触敏捷概念的小伙伴，还是职场经验丰富的老鸟都可谓是能够轻松吸收。 从第一天的培训课程开始，BoB老师就没有照本宣科机械介绍PPT的培训讲义，而是从敏捷的兴起创始人小故事讲起，逐步代入到敏捷宣言的提出以及敏捷宣言遵循的原则，并通过幽默诙谐的方式对其中的核心内容进行讲解。当讲到用户故事的时候，为了让大家理解什么是用户故事，以及怎样来写用户故事，通过随机分配六人小组，合作完成一个”敏捷介绍”视频制作的小实践时，同学们通过快速分配角色，共同出谋划策，在7分钟的时间内，写出10-15条用户故事，然后BoB通过对每组每条用户故事的详细点评，指出不足，再来一轮脑暴完成修订版的用户故事输出，整个过程同学们参与度极高，对用户故事怎么写有了充分的理解并获得了实际经验，相信能很快在实际工作中做得更好！ 最开心的是，这个小敏捷实践过程在短短的不到1个小时的边讲解边实战过程中，所有小组的成员都完成了”交付”，很多小组都交出了非常漂亮的最终产品，获得Bob老师以及小组间的相互认可！ 核心的Scrum框架内容在轻松愉快的氛围中结束后，第二天的课程更加精彩，BoB老师精心准备了大量实战案例，比如BoB老师作为敏捷教练，在自己曾经服务过的企业京东的电商敏捷交付团队，通过对实际案例中的具体实施细节以及遇到的问题的深入剖析，以及具体实施细节，比如产品代办列表（Product Backlog）、冲刺代办列表（Sprint Backlog）、产品增量（Increment）等的实际例子，详细讲解实战中过程中遇到的坑和如何填坑的过程，非常精彩！ 而培训的过程远不止Scrum框架的内容，BoB还通过一些手绘以及小视频方式为大家带来了规模化敏捷的演变过程，通过对spotify大规模敏捷之路的讲解，让我们深入理解了对于较大团队的敏捷如何实施。 在最后半天的培训课程中老师还给我们带来了”彩蛋”：敏捷项目经理的职业规划。这个内容对于很多职场人，尤其是正在做项目经理，或者希望转型做项目经理的人来说，无疑是非常有指导意义的。BoB老师很谦虚的通过自己的职业转型之路，为同学们用实际案例介绍了学完CSM以后，所能带来的个人成长，以及将来可以规划的职业路线，通过对”百万收入的自由职业者”的理解和分析，定了一个格调：先要成为职业者（专业领域佼佼者），再谈”自由”的合理性，受教良多！ 由于培训课程时间较短，内容多，老师并没有过多展开这方面的讲解，毕竟不是CSM培训的内容，但是课后我本人又跟老师约了时间，通话将近一个小时，说了自己的情况以及今后的想法，老师都跟朋友聊天一样，帮我分析了我的优劣势，以及今后努力的方向，并给我介绍了进阶课程进修的专家级讲师，在此内心非常感激！ 最后做个简单的总结，两天课程的培训，我第一时间考取了CSM的证书，如果满分100分，我给BoB老师的课程打110分！多出来的10分，就是对老师超出培训内容所给出的职业规划建议以及给我本人的非常详细的建议，再次感谢Bob老师：谢谢老师，您辛苦了~ 来自学员 Tony Yue CSM信息大全 想要约 CSM 课程，扫码 –
2020/5/17
articleCard.readMoreScrum：用实验主义应对复杂问题的优秀框架|参加Bob线上CSM课程总结
此图是2011年我工作总结的片段，那是我第一次做网站，也是第一次尝试Scrum。毫无疑问，Scrum真的是用实验主义应对复杂问题的优秀框架！ 在2017年上CSPO课程之前，我的Scrum知识主要来自于相关书籍或者网文，比如《硝烟中的Scrum和XP》、《精益开发实战》，因为创业和职业发展咨询师的经历，也一定程度的掌握了”精益创业”和一对一咨询技术。我对Scrum的实践是断断续续的，最持续、效果最好的一段是2018年在深圳做电商与直播产品的一年，然后就是从2019年8月开始到现在。 很诚实地讲，作为从9年前就开始尝试Scrum方式管理软件开发的俗家弟子，上5月16到17号Jim和Bob在线教授的认证ScrumMaster培训课，依然收获很大。 总结思考这次上课，我问了自己三个问题，希望对其它小伙伴也有帮助： 我有哪些重要收获？ 为啥实践Scrum很有挑战？ 对打算上课的小伙伴有何建议？ 我有哪些重要收获？ 上课前后我对Scrum的理解，用图来示意，我想会是这样： 即，课程帮我： 因为是个人兴趣和精力限制，我并没有正式将Scrum导入团队，有点”悄悄地进村，打枪的不要”的意思。我也觉得这样切入阻力比较小，但缺点也有：多重角色、耗心费力。也许，有不少跟我类似的人:)。 如果做个对比，使用Scrum框架进行产品开发/项目交付，可能与做一个产品经理有点像：说起来工作”活动”就那么几个，但做起来却需要关注（Cao Xin）无数的细节。 虽然在实际工作中，我不断验证了自己做法的有效性、总结出少许经验，但也体味着模糊不清、定见不足的感受： Sprint任务提前完成该提前结束么？ 多人异地办公怎么玩？ 前后端的人没办法同时进入新产品开发组还能搞么？ 产品涉及不同小组协作开发要怎么搞？ 软硬件开发周期不同怎么搞？ PO同时做Scrum Master的坑要怎么避？ 怎么让开每日会变成团队习惯？ 写日报真有价值么？ 并行项目好几个怎么保持专注？ PO和产品经理怎么协作？ 这两天的课程让我相信，我的接纳不是放弃，妥协是个合理过程，前辈走过了、同行也在走。Scrum是应对复杂问题的经验框架，但不是”最佳实践”，”最佳”取决于团队自身、实践者自身、所在的当下。里面有太多的空白需要用热情、技巧、橡皮泥、强大的肌肉、发光的金子、咕咕的清水……去填充，只要我们相信文化、坚守原则、积极学习，同时接纳不足、明白这得有个过程。需要开放与勇气。 为啥实践Scrum很有挑战？ 两天的课上对Scrum的框架讲解非常透彻，同时也重点讲解了PO和Scrum Master的职责和技能要求，挑战亦源自于此。我想对于一个从事软件或系统开发的新人来说，参加这样的培训，而不仅仅是自己看书，会更加明确自己未来职业发展的方向、自己的喜好和用力的方向。用图来代表一个初学者的状态，可能会是这样： 知识框架有空白、缺少条理是一方面，欠缺更多的我感觉也许是这些： 这也就是为什么还有A-SCM课程的原因，至少能在其中两到三个方面给与快速进步的学习机会。从一个A-SCM培训课程大纲里也可以看出这些： 从”为什么”开始→敏捷的意图→复杂系统思考→打造自组织团队的技巧→创新组织生态系统角色能力模型→敏捷教练能力模型→催化蜕变的技巧→组织设计和多团队扩展→冲突管理→内在驱动力→影响力与变革模型→软技能：教学→软技能：指导→软技能：引导→软技能：教练→敏捷教练工具箱。 如上这些技能、方法、理念，我也掌握一部分，则是在其它的培训、阅读、创业经历和工作实践中习得的。 对打算上课的小伙伴有何建议？ 其实这是老生常谈的话题了，简单点说就是：请全情投入！ 上课过程中有多次互动协作环节是分小组进行的，通常会出现一个引导推进的角色、一个实时记录进度和成果角色，其它小伙伴同频参与，随时发现待办事项并认领去做——这也是典型的Scrum活动。 非常建议在上课前，自己对自己有个自我激励与判断，是否打算主动做引导推进的工作，或实时记录进度和成果的角色。如果适应新环境需要一个过程，则可以先做到同频参与，等感到安全的时候再主动来做。最好是小组中的每个人都有机会承担这样的角色一次，因为只有这样才可能表明，自己真的全情投入了，给自己一个这样的承诺。我上课的那两天，显然有的小组缺乏这样的角色，似乎组里每个人都在被带领、被激活。即使有人蠢蠢欲动，也有些不好意思的感觉。那么，如果你也正好被分配到这样的小组会怎么做呢？请问下自己…… 如果要上的课程也是在线的，做到认真聆听、热情参与、积极协作、全情投入，请尽量让自己处于比较安静与隔绝的环境中，别挑战自律能力^_^。 最后，提醒一下打算上课的小伙伴，要在上课前去网上了解一下Scrum的核心及相关内容，不至于感到很陌生，完全处于接受信息的状态而疏于思考——毕竟只有两天的课程，知识点是很多的。 作者：智能物流机器人创业公司产品开发与项目部负责人，Scrum实践者，带领的团队角色包括产品/项目经理、前后端开发、UI设计、运维、数据分析师，现在则还多了机械、硬件、电气、现场实施工程师，做过一些有趣的事情。
2020/5/16
articleCard.readMore在远程 CSM 课程中体验线上工作坊
转载自 诺普博客 4.11 日周六，我参与了由 Bob 老师组织讲授的一期 Certified Scrum Master（即 CSM）课程，从中收获颇丰，特记于此，与君分享。 CSM 通常是现场授课，但本次由于疫情的限制导致人们不得不尽可能减少外出。而 Bob 老师也适时地将原本现场的授课改为了远程的方式。吸引我参与这次课程的，正是这种远程授课的安排。因为正是受制于目前的困难情况，我所在的红帽开放创新实验室的不少活动也难以高效开展。所以参与本次课程的目的，除了学习 Scrum 之外，我还想了解一些远程引导的技巧并观察与我一同参与课程的其他同学的情况。 本以为可能不少人会出于对远程授课效果的担忧而不倾向于参与远程课程，但临到开课前组织的微信群的参与者竟达 30 多人，着实令人意外。在开课之前，Bob 老师还在微信群里发来了第二天上课用的 Zoom 会议链接，并提醒大家提前装好 Zoom 软件。 课程于 4.11 日早九点开始，一共两天。第一天主要讨论了敏捷和 Scrum 的基本概念，并介绍了 Spotify 大规模敏捷的实施案例，第一天结束时 Bob 老师给大家留了家庭作业；第二天以回顾各位的家庭作业开始，之后我们逐个探讨了 Scrum 的各种角色和事件等关键内容。作为练习，大家还以分组、迭代的形式制作了一个 Scrum 视频，成为了课程的意外收获。课程结尾时，Bob 老师给大家讲解了 CSM 考试的注册流程和注意事项，并祝愿大家获得好成绩。 下面我尝试从”线上课程引导”、”课程内容呈现”和”课程准备工作”等几个维度来解析这两天的课程。 线上课程引导 第一天早上九点开始后，一开始 Bob 老师就向大家介绍了两天的时间安排，以及 CSM 课程对出勤时间的要求。后续他采用了一些方法来确保大家确实有效地在关注课程内容。首先，大家在微信群里，使用 Zoom 软件提供的”注释”功能，在屏幕上写下了自己的名字。对于很多之前没用过此类功能的同学来说，是个新奇的体验。从截图来看，大家玩的不亦乐乎： 接着是自我介绍。由于是课程在周末，出于隐私和网速等方面考虑大多数人并没有开启自己的摄像头，这给自我介绍凭添了”一屏幕的距离”。Bob 老师很快利用 Zoom 软件的”小组会议”的功能将大家分成了 6 个小组。这样每个小组就只有 5、6 人，介绍起来轻松自如。同时，自我介绍环节限时 6 为分钟，平均到每位同学只有一分钟的时间。在我所在的第 6 小组就出现了由于某些同学花的时间太长，导致后面的同学时间不足的情况。 在中途某个时间，我发现 Bob 老师溜进了我们小组，但他并没有出声。这种情况与现场讨论时，讲师到处”偷听”的情形倒是很类似。这一环节快结束时，在 Zoom 聊天框里能收到讲师发来的时间提醒，同时屏幕开始倒时一分钟；倒计划结束时，所有小组讨论自动结束、所有人回到”主会场”。 这个短短六分钟的自我介绍环节，让我倍感欣喜。虽然之前我使用 Zoom 会议软件已有几年经验，却从来没有使用过”分组讨论”的功能。由于参与者众，如果每人轮流给所有其他人介绍自己，估计很快大家就难以保持专注。同时，由于额外的”一屏幕距离”，也会让大规模的自我介绍难见成效：相互看不到其他人、人数又众多，结果就导致所有人都记不住别人是谁、他说了什么。恰是这种分组讨论的方式有效地防止了这一情况。
2020/5/16
articleCard.readMore查漏补缺，更上层楼 | 参加Bob老师CSM课程总结
4月11日-12日参加了Bob老师的在线CSM课程，2天的课程可谓是查漏补缺，我虽从2016年开始就通读且组织团队一起学习了Bob老师翻译的《Scrum精髓：敏捷转型指南》一书，并且在企业中帮助企业产研团队乃至相关辅助职能部门敏捷化转型，有几年实战经验，但回头来听Bob老师的课，依然有很多的启发和收获。 首先，是长了见识，既学习了敏捷相关知识，也学习了如何授课相关知识。比如可以学习老师是怎么组织自己的课堂内容的，比如老师会用什么方式来串讲各类基础知识。这是一门基础的课程，但老师却会结合比较多的实践来讲解，也或者自己实践了比较多，在老师讲解的时候，会联想到很多画面，所以听起来也就感觉很饱满。 老师在课堂上很注重理念和实践的结合，一些理念的东西是怎么在我们的实践中体现的，老师会直接举例，也会通过问问题的方式让我们自己思考，也会让我们分成小组来讨论和共创一些内容，比如敏捷理念和敏捷价值观可以作为我们回顾会议的输入，以便于更好的引导大家思考可改进点，比如我们一起在10分钟内做个宣传的视频，这也激起了大家浓厚的兴趣，老师还会分享一些成熟的公司的敏捷案例，其中spotify的案例，至今还在我脑海里回旋，我的第一反应是，社区的实践或许可以引入到我现在所在的企业，激发了我想在企业内部创建一个敏捷社区的想法。 其次，还收获了一些工具和书籍。比如老师在实践中会用哪些工具，老师上课时会用哪些工具，老师在课堂上还推荐了好几本书。让我想要学会的工具比如制作视频的一款绘画工具叫laihua ，可以有手绘制的感觉。老师提到《驱动力》讲到目前来看：外驱力越来越不明显；内部驱动力在起作用（前提：钱要给够）；内驱力：Autonomy自主、Mastery专精、Purpose目标。老师还推荐一本《高绩效教练》的书，提到引导的原义：让事情变得简单。敏捷教练：经常会有组织会议的要求，会议上，让大家在最短的时间内达成一致，这就是引导。还有《裂变式创业》等。 最后，收获了一群有共同兴趣和热情的希望能在敏捷领域有更多实践和探索的同学。我们不仅在课堂上有分小组讨论的小组同学，还有分享个人经历的一次对话的同学，我们还有相约1个月后来相互check对方1个月要达成的目标是否达成的目标约定的同学。事实上，21天让人养成一个习惯，如果我们能够约定1个月的目标，并去达成，我们就会收获一个好习惯。所以，这不仅仅是目标的达成了，这还是一个良好习惯的养成。建立这样一个好习惯，相信，会受用一生。 最后，总结一句话，2天的课程，远远不止2天的收获。2天的课程，它就像是有了生命的种子，让来参加了学习的人从此开始在敏捷这条路上，像滚雪球一样，让人可以不断进行下去。感谢Bob老师的精心准备和耐心的讲解及分享。 来自学员 欧阳 CSM信息大全 想要约 CSM 课程，扫码 –
2020/5/15
articleCard.readMore敏捷的潘多拉魔盒 | 敏捷家分享008
内容来源：敏捷+社区线上直播008期，《敏捷的潘多拉魔盒》分享实录 分享者：李聃 关注本公众号回复”潘多拉”即可获取本次分享的视频回放、下载PPT 今天我给大家带来了一些关于敏捷方面的分享，也希望大家能有所收获。由于疫情我被困在了家中，所以在此我插播一个广告，非常感谢敏捷家及网易杭研组织这次课程，同时也感谢Bob老师以及在场的各位小伙伴。 今天我要分享的Topic是敏捷的潘多拉魔盒，当然了在讲课之前先做一个自我介绍，我叫李聃，我的聃和老子同名，我的姓也和老子同姓，所以我跟老子是同名同姓的。在我过去的16年的工作经验中，将近有10年是在做项目管理工作的。近5年其实我主要是公司的PMO负责人，管理公司的项目，并帮助组织做一些敏捷转型的相关工作，也辅导过很多的敏捷团队，也组织过或者作为演讲嘉宾参加过国内的一些敏捷或DevOps大会，并翻译过相关的一些书籍。关于专业认证方面，我有41个国际认证，包括项目管理、产品管理、精益敏捷、DeveOps、规模化敏捷和IT服务管理，同时我也是非常热门的火星着陆器和凤凰项目的沙盘授权讲师。 下面我们正式进入今天的课题，今天要分享的内容主要是围绕着敏捷及敏捷的一些反模式的话题所展开的。它其中包括4个小节： 乌卡时代的魔盒 潘多拉打开了魔盒 敏捷魔盒中的这些冰与火 敏捷魔盒中的最后的希望 我会通过几个故事和大家聊一下敏捷这个事情。 VUCA时代的魔盒 下面我们开始一起来揭开今天的潘多拉魔盒。说到乌卡这个词，它是由美国陆军在90年代初提出的一个概念，它是应对冷战后世界形势的一种解读。乌卡是由易变性、不确定性、复杂性、模糊性这4个英文单词的首字母所组成的。既然世界形势发生了变化，战略方针、战略行动、组织结构也应该随之而变，所以组织也应会应对这种战略、战术和组织结构做出相应的调整。个人应该做出什么样的转变呢？我觉得可能个人需要做到有愿景、有知识、有勇气和不断适应。 查看原文获取更多材料和音频
2020/5/10
articleCard.readMore自由职业者心态
为什么需要自由职业者心态 不论你现在是自由职业者，还是上班族，都需要具备自由职业者心态。2020年突如其来的状况，让很多企业（或个人）陷入了危机。也让Bob陷入了深深的思考。如何构建一个健康的收入结构，以应对未来可能更严重的情况呢？ 这里就需要一个自由职业者的心态。（以Bob三年多的自由职业者经历，进行梳理总结） 什么是自由职业者心态 自由职业者心态就是不断的挑战自己，不安于现状。自由职业者心态第二层含义是，变现的心态。只要提供的有价值的服务都是可以变现的地方。比如说你身边的同事总是在找你问一些问题，那你可以反思总结这些问题，自己反思完总结下来的东西就是可能变现的地方。 所以自由职业者心态目前有两层： 第一挑战自己，走出舒适区 第二商业变现的心态 但是自由职业者的心态并不是说真正的自由（完全放飞），只有自律才能带来自由。不自律的人只能成为他人的粉丝，为他人打工。 走出舒适区 每天的生活与工作，你是在重复昨天，还是在不断挑战自我？ 面试的时候，你是一个有十年工作经验的员工（但是十年如一日的重复） 还是一个有3年工作经验，但是3年的经历非常挑战，每天都在创造奇迹？ 如果你是面试官，你会选择哪个人？ 变现 一个不知道如何变现的自由职业者，可能并不是一个好的自由职业者。谈钱并不可怕，当自由职业者提供了有价值的服务后，获得报酬是应该的事情。 免费是最贵的…… 因为免费要的是你的注意力，每个人的注意力（时间）就那么多，不会增加也不会减少。随着时间推移一点一点的消耗掉，如果不在看这篇文章，或许你就在刷微信。 所以作为自由职业者，不能是过多的时间去刷刷刷，会沉迷的…… 如何成为自由职业者 自由职业者并不是一开始就是自由职业，大部分的人都是从企业走出来。成为自由职业者最重要的要求是什么？ 第一自己的核心能力，也就是你可以变现的地方 第二整合能力也叫连接的能力。为了做成一件事情，你需要去连接其他的服务提供商。 或许有的小伙伴会说，我的收入都是上班的薪水，没有其他收入。那这里就是有一个大大的问题送给你。 10年后，你还想像今天这样吗？（如果不是，你希望自己成为什么样子的人？） 种一棵树最好的时间是10年前，其次是现在。 是时间认真思考一下你的树是什么，现在种上你的树吧。（至少现在播下你的小种子） 种子就是你要培养的能力，对于自由职业者，我之前采访过两位（加上我有3位）。 我们三个人有一些共性的能力，可以供你参考。 虽然大家从事的行业不完全一样，有从事培训行业的、从事咨询行业的、有从事软件开发的，那还有从事写作。我们共同的能力如下： 写作 营销 社群 第1个是写作，第2个是营销，第3个是维护自己的社群。所以如果你还没有开始做以上三件事情，现在就开始做（播种）。 写作 写作是我现在锻炼的一项能力，也是我一直在锻炼的能力。这篇文章的写作就是用讯飞输入法语音转文字进行写作的。这是非常高的效率来进行写作，以前我们在写作的时候，大部分的印象都是坐在电脑面前手敲键盘来进行输入，而实际上当我们这样做的时候，很多时间我们是思路会被打断的，因为我们在打字的时候有可能会打错字，有可能我们会进行排版，那当你进行语音写作的时候，你的思路是流畅的，所以呢，非常建议大家可以进行语音写作的输出。（每天10分钟语音输出） 营销 第2项能力是营销。营销这个事情是非常广泛的，但并不是说发发微信朋友圈，在微信群里面发几篇文章，这就叫做营销。营销是一整套的事情，必须要去综合考虑的（吸引，信任，下单；三个阶段形成漏斗）。可以做的是把营销和社群要结合在一起。比如说你有一项斜杠的能力，比方说我现在是自由职业者，我会创建一个自由职业者俱乐部的社群，维护一群相同标签的人。在这里大家可以互相学习，互相交流。 如果你觉得这样的社群离你很远，可以做一个读书俱乐部。虽然说市面上已经有很多的读书俱乐部，你可以做自己的，每个人想读的书是不一样的，每个人从书中获得的收获也是不一样的。如果你读了什么书，然后引起了一些人的共鸣，你就可以找到自己的伙伴，大家一起共同来读书。那在这里面推荐大家来听一下，我对于《Scrum精髓》这本书的阅读。读书笔记也欢迎大家来订阅黄金屋知识星球，在这个知识星球里面，我会不定期的分享我读过的一些书和一些反思收获。 社群的意义 为什么我会说社群这件事情？因为社群就像土壤，我们每个人都会同一个时间参与了很多不同的社群。有的时候可能你不认为这是一个社群，比如说公司里面的篮球俱乐部，足球俱乐部，前端兴趣小组，公司内敏捷社区，健身俱乐部，减肥俱乐部等等，这些都是社群。我们每个人身上会有很多的标签，每一个标签都有可能会形成一个社群。每个人也都可以发起自己的社群，当你发起自己的社群，有自己的粉丝之后，你就在创造影响力。 所以说社群就是土壤，每个人是植根于社群里面，也与不同的社群有相互联系的。每个人又可以从社群当中吸收养分快速成长，然后又可以辐射到更大的社群，产生更大的影响。所以现在赶紧动手去打造你自己的社群吧。 打造社群当然会有很多坑，必须要自己去做了，踩坑后才知道怎么做。 当然你也可以联系 Bob 进行取经。 总结 走出舒适区 找到变现的能力 开始写作 打造社群并开始营销 最后附送大家4个问答。 自由职业者微信群问答互动 为什么会想到聊这个问题？今天在自由职业者微信群里，有小伙伴问起了几个问题 姜老师，对于自由职业者，我有以下的困惑。如果今后访谈中能够涉及这些问题，我将非常感谢。 Q1: 很多工作场景主要存在于企业中，离开了企业的土壤，自由职业者该如何做知识更新？ A: 工作场景都存在于企业，你这个假设不一定成立。 自由职业者的知识更新，会有很多渠道：读书、参加社群、上课……
2020/5/10
articleCard.readMore重温Scrum精髓 - Scrum的核心到底是什么
为什么写《Scrum精髓》 2014年我和两位好友左洪斌、米全喜一起翻译了《Scrum精髓》这本书。翻译完这本书之后，在整个敏捷社区里面还是引起了蛮大的影响。到目前为止已经印刷了超过2万册。但是即便是这样，依然有很多人和很多团队并不了解Scrum的精髓到底是什么。因此今天想来跟大家聊一聊Scrum精髓这一个很重要的话题。 2016年我申请到了Certified Scrum Trainer (CST)。这段旅程让我对Scrum有了更深一步的理解。这几年在培训过程当中，我也发现了学员最常问的问题，比如说，Scrum团队如何进行估算，Scrum团队如何进行绩效，Scrum团队怎么来考核他们，Scrum团队应该选择什么工具？等等等等，每次培训都会有大量的这类问题。 这让我对于Scrum的推广深感不安！推广Scrum这么长的时间，依然这么多的人不了解Scrum的精髓！ 因此今天特意写篇文章来澄清一下Scrum的精髓到底是什么？ Scrum精髓是什么 在介绍Scrum精髓之前，先说说Scrum精髓不是什么。有很多的小伙伴认为Scrum不就是3355吗（简单好记）？其实Scrum的精髓根本就不是这些。Scrum也不是流程，Scrum也不是工具。Scrum是通过交付产品的方式，来解决客户的问题，这句话是站在Scrum教练的角度上来说的。 Scrum精髓 Part1 - 解决客户问题 作为Scrum教练就是要帮助客户解决他的问题，Scrum只是帮助客户很好的交付产品一种方式。这里是站在Scrum教练的角度上来说客户去交付产品，那为了要能达到快速的交付产品，Scrum只是第1步。在这非常重要的第1步，很多个人、团队和组织都在做反Scrum的模式。比如说他们更看重流程，更看重角色，而忽视了团队，忽视了团队内的人与人之间的连接，也忽视了开发团队与真正用户之间的协作，这些对于Scrum都是非常的重要（其实不仅仅Scrum，应该是客户的核心价值）。 所以要看Scrum转型组织追求的目标是什么，如果只是追求一堆度量数字，恭喜你走错了。最终的目标一定是要让客户满意，要让客户的最终用户满意，帮助客户解决他的问题，那你在解决问题的过程当中，Scrum只是第1步而且是非常重要，且要坚持的第1步。那除去Scrum还有很多其他的方式，现在市场上有很多都是过度包装进了敏捷，其实这是一个很不好的现象，尤其是SAFe，DevOps，大家更加看重组织分层，更加看重工具，更加看重流程。 Scrum精髓 Part2 - 关系 Scrum精髓的第2部分就是团队成员之间的关系，团队与客户之间的关系。这些关系处理不好，那用什么方式都是无用的。另外对于Scrum精髓，就是帮助客户真正的提高交付速度。只有提高了交付速度，才能不断试错，才能去探索方向。如果你的交付速度提高不起来，那就没有办法去做到快速应对变化。 Scrum精髓 Part3 - 反思 每天作为Scrum Master应该反问自己、反问团队，我们现在是否帮助客户解决问题了，我们和客户的关系怎么样？通过每天不断的反思，不断的问这些问题来促进团队成长。 Scrum的反模式 对于Scrum的模式，有三个常见的： 第1个就是以流程为中心 第2个是以考核绩效为中心 第3个组织“推动”敏捷转型 以流程为中心 Scrum不是没有流程，但不能是SQA的人来搞流程，也不能是不做开发的同学制定流程。因为这些人制定的流程，是死的，不适合团队，也不会轻易改变。流程是用来提高工作效率的，适合团队才是合适的。更重要的是团队一起反思如何更快的进行产品交付。而不是如何制定一个更完美的流程。 以绩效为中心 度量什么，就得到什么。 – 彼得德鲁克 绩效是一把双刃剑，也是背景驱动的，即不同的团队采用不同的绩效，没有正确的绩效也没有不变的绩效。所以还是回到Scrum精髓的本质，把团队的注意力拉回到正确的路上。 “推动”敏捷转型 很多的组织都是“推”敏捷，员工是被推着走，管理层也是被老板推着走。没有人愿意主动寻求改变。这种情况下，还是洗洗睡吧，别折腾了，到最后大家都很累。何苦？ Scrum转型，需要是团队、管理层、老板都一致认为，我们需要改，理解驱动力（WHY）。 总结 所以Scrum的核心，精髓有三点 （需要日日反思）： 解决客户问题 关系 反思 做不到以上三点，就不要硬上Scrum，上了也没太大好处。因为采用Scrum之后，团队不断暴露问题（或者用新的方式隐藏问题），没人愿意接受，也没人愿意改进，何苦呢？ 最后那你理解的Scrum精髓是什么？你认为什么才是Scrum真正核心的内容？
2020/5/8
articleCard.readMoreNEAR 黑客马拉松 (Gitcoin)
Ready Layer One的HACKATHON (Gitcoin虚拟黑客马拉松) 现在报名 5步赢得1000美元奖金！！！ 时间：2020年5月6日-2020年5月19日 赞助商 - NEAR协议 Ready Layer One黑客马拉松是为期一周的虚拟hackathon，紧随Ready Layer One会议之后。在黑客马拉松期间，黑客将在下一代区块链协议之上构建项目，以争夺加密货币大奖。立即注册以通过电子邮件接收更新，然后于5月6日返回hackathon启动，以查看奖品，结识黑客并开始建设！ HACKATHON如何运作？ 查看奖品 访问奖品浏览器，查看由黑客马拉松赞助商发布的奖品。单击每个奖项以显示重要的详细信息，包括提交要求，提交截止日期等。 加入Hackathons聊天工作区 与其他黑客聊天，向发起人和Gitcoin团队提问，找到或创建一个团队，并进行实时交流。单击此处加入聚会！。 通过Gitcoin开始工作 组建团队后，请您的一个队友导航到您计划竞争的每个奖金页面，然后单击”开始工作”按钮。 开始构建！ 建立您的创意，使您的团队实现您的愿景！ 通过Gitcoin提交作品 项目完成后，请点击奖品页面上的”提交作品”按钮/ 现在报名 奖金设置 本次黑客马拉松一共设置9个奖项： 参与奖 - 没有中奖的合格提交者，将获得75美元奖励 打造有趣的东西 - 1000美元 Flux协议的实现 - 1000美元 学生奖 - 500美元 互操作性奖金 - 1000美元 访问性奖金 - 1000美元 社交互动技巧奖金 - 1000美元 金融 - 1000美元 全球奖金 - 1000美元 更多奖金详情，可以点击这里。
2020/5/5
articleCard.readMoreOKR痛点与误区 | 敏捷家分享007
内容来源：敏捷+社区线上直播007期，《OKR中的误区和痛点》分享实录 分享者：杨瑞（大叔杨） 关注本公众号回复”痛点”即可获取本次分享的视频回放、下载PPT 大家好，我叫杨瑞，也可以叫我大叔杨。我专注在敏捷转型咨询，也算是国内做敏捷教练比较久的。自己做过很多事，包括：研发管理、传统的CMMI、产品、创过业，折腾过好多杂七杂八的事。我是DevOps社区的核心发起人，全国很多敏捷社区的参与者，做过很多年RSG的分享嘉宾。 最近一段时间OKR的话题特别热，从疫情开始的时候，我就开始做这个话题的撰写。用了一个多月的时间，形成了OKR的微课。这个课程叫做《敏捷圈必学的OKR》，我觉得敏捷圈的很多人应该去学学OKR，我用的这两年，在客户的落地过程中，确实体验到了它的甜头，包括今天下午还在跟客户沟通OKR和考核的事。 看到大家在使用的过程里面有很多问题，也有很多的疑虑。于是就打算做一个痛点和误区的分享，话题写的内容不多，也没有做太多的准备，都是现有的一些资料做了一些拼装组合。我觉得具体的很多问题大家可以在群里来讨论，因为白天的时间大部分在客户那边，有些时候能回复一些问题，有的时候可能看到问题也没法回复，所以我觉得晚上的时间可以慢慢跟大家聊。 痛点和误区1：OKR和KPI 我们来看第一大痛点和误区，就是OKR和KPI。很多团队或者说90%以上的人在这里面都不会犯错。 1.1 OKR和KPI的关系 首先我们先给大家做两个普及，OKR到底是什么？ 查看原文获取更多材料
2020/5/3
articleCard.readMoreOKR新手入门指南 （第三部分）
您的OKR应该有多雄心勃勃？ 雄心勃勃的目标是如此重要，以至于Google 众所周知的十件事直接提到了它们： 我们为自己设定了目标，我们知道我们还无法实现，因为我们知道，通过努力实现这些目标，我们可以超越预期。 雄心勃勃的目标也称为延伸的目标。但是延伸的目标到底是什么？ 拉伸的类比 让我们考虑一下拉伸的特征： 当您伸展运动时，会感到不舒服，甚至有些痛苦。伸展运动会使您脱离舒适区； 伸展运动时可能会感到不舒服，但之后会使您感觉良好。 拉伸的整个想法是尝试到达一个您无法到达的地方。即使您知道自己无法达到目标，也必须继续努力。 定期拉伸后，您开始伸手可及的距离，如果您没有拉伸过的话。您可能仍然无法站立，但是现在您可以到达以前无法到达的地方。 尽管拉伸感觉不舒服，但您不应该拉紧肌肉。您不应试图伤害他人。您可以尝试当Jean Claude Van Damme，但要花点时间。 这如何适用于目标设定？ 当您考虑这个类比时，您可以说延伸的目标就是以下目标： 带您离开舒适区； 让您追求您认为无法达到的目标（至少尚未达到）； 使您实现以前无法做到的事情； 应该很努力，但要不至于伤害（或使您失去动机）。 将延展目标视为很难实现的目标，以致团队重新思考工作方式，提出棘手的问题并避免了艰难的对话。延伸目标使团队想知道他们能走多远。 实际上，在一项长达35年的经验研究的荟萃研究中，设定目标理论的先驱Edwin Locke和Gary Latham发现了科学证据，表明”最高或最困难的目标产生了最高水平的努力和绩效。” 正如拉里-佩奇（Larry Page）在《Google工作原理》的前言中所写，让人们认为做大事很难，而大胆的目标则是关键： [团队]倾向于认为事情是不可能的，而不是……弄清实际上是什么。这就是为什么我们投入大量精力在Google聘请独立思想家并设定重要目标的原因。 ” 70％是新的100％” 里克-克劳（Rick Klau）展示OKR的视频观看次数超过450,000。克劳在其中提到： 目标是雄心勃勃的，应该感到有些不舒服。 OKR等级的”最佳点”是 0.6-0.7；如果某人始终获得1.0，那么他们的OKR不够雄心勃勃。如果您得到1，则说明您没有将其粉碎，而是在装沙袋。 克劳（Klau）的声明引起了一些质疑，即”如果接受的结果是70％，那么新的100是70吗？”。 仅当团队不努力时，才会发生此问题。将70％的目标作为目标就像只触摸您的腿而不试图伸直脚 - 即完全不伸展。延伸目标的整个想法是继续尝试达到100％，即使您知道大部分时间您都无法达到目标。 月球射击与屋顶射击 （类比） 克劳描述的OKR类型称为” 月球射击 ”。实际上，还有第二种OKR，即”屋顶射击”。下表说明了这两种情况： 月球射击 伸展目标。 刚刚超出了可能的极限。 成功意味着达到60-70％。 屋顶射击 艰巨但可实现的目标。 成功意味着达到100％。 Moonshots（月球射击）是OKR的基础构建块，但是它们需要大量的组织成熟度。以我的经验，月光会引起一些问题： 他们可以激励团队 人们喜欢击败目标。只有实现60％的OKR才能使其中许多人失去动力，尤其是在一开始的时候。
2020/4/29
articleCard.readMoreOKR新手入门指南 （第二部分）
OKR的主要好处是什么？ OKR的主要好处是： 敏捷性： 较短的目标周期可以更快地进行调整并更好地适应变化，从而提高创新能力并减少风险和浪费。 协调和跨职能合作： 使用共享的OKR可以改善不同团队之间的协作，解决相互依赖性并统一竞争计划。 减少设定目标的时间： OKR的简便性使目标设定过程变得更快、更轻松，从而大大减少了设定目标所花费的时间和资源。 清晰的沟通： 透明度和简单性使团队能够了解组织的目标和优先事项以及每个人的贡献方式。 员工敬业度： 确定目标的OKR双向方法将员工与公司的目标联系起来，从而提高了敬业度。 自主权和责任心： 团队会收到明确的指示，可以自由选择如何实现其OKR。他们以自己的目标为己任，并以整个公司熟知的明确成功标准为己任。 重点和纪律： 减少的目标数量将重点放在组织上，并约束工作和计划。 更大胆的目标： 将OKR与薪酬脱钩，甚至部分使用拉伸目标，使团队能够设定更大胆，更具挑战性的目标。 战略OKR与战术OKR：嵌套节奏 一个普遍的误解是，OKR仅适用于季度周期，这是Google一直使用到2011年的模型。在担任Google首席执行官一职后，Larry Page决定采用年度和季度OKR。 我们只能猜测促使佩奇做出决定的原因，但是大多数公司最终发现，使用短期OKR可能会导致团队错过总体情况，只专注于三个月内可以完成的事情。 大多数成熟的OKR实施都知道，不同的目标会有不同的节奏，因为战术目标的变化往往比战略目标快得多。因此，正如我在本指南开头提到的那样，OKR通过采用嵌套模型将策略与策略脱钩： 具有公司高层，长期OKR的战略节奏，这不是一成不变的。组织应保持有关战略的持续对话，并在必要时审查公司的OKR。 团队具有短期OKR的战术节奏。 具有常规签到的跟踪节奏，可沿途跟踪结果。 如果您选择向董事会展示战略OKR，那就会让董事会感兴趣。 我在成功采用OKR时看到的一种模式是： 公司的年度战略性OKR（有时是非常大的部门和业务部门）。 每季度为各小组提供战术性OKR，并进行季度中期审查。 每周检查以跟踪结果。 一些组织还为公司设置了季度OKR，但一开始我不建议这样做。 选择您的OKR节奏 需要注意的是，组织可以根据自己的需要定制节奏。例如，Spotify的战略周期为六个月，而其团队则每六个星期确定一次OKR。这是一个有趣的故事，因为他们在尝试创建自己的方法后，又重新使用了OKR。 奇点大学（Singularity University）的创办执行董事Salim Ismail在他的《指数组织》一书中写道： 许多组织现在正在实施高频OKR，即个人或团队每周，每月或每季度的目标 大多数试图设置每月OKR的团队都将OKR用作待办事项列表。当团队使用OKR来衡量价值时，正如我们将在以下各节中看到的那样，每季度的节奏很有意义，因为您需要时间来制定计划，衡量其影响并进行迭代。 通常，节奏越短，OKR设置的开销就越小。节奏越长，业务不确定性就越低。 因此，要缩短周期，您必须确保拥有简化的流程来开发OKR，否则您将花费太多时间设定目标。 另一方面，如果您的业务面临不确定性或市场变化太快，那么较长的OKR周期将无济于事。 如果您是从OKR开始的，那么我建议您每季度使用一次战术节奏并进行季度中期审查。这将使您能够学习和适应模型。大多数组织都可以使用这种节奏。 从统一节奏开始 在硅谷，一些成熟的公司对于不同的职能有不同的节奏。例如，一些公司为销售团队设置年度OKR，而对工程和产品团队使用季度OKR。 我建议从每个人开始使用相同的节奏，因为这样可以减少复杂性。最好的方法是从一个更简单的模型开始逐步进行部署，然后根据您的学习逐步发展。 如果您想最终在组织内部设置不同的节奏，则应尝试最大程度地增加”同步机会”的数量。例如，让一个团队使用4个月的节奏，而公司的其余团队使用3个月的节奏，则意味着团队每年仅同步一次，这可能会严重影响一致性。 OKR不级联 在传统组织中，目标是级联的。看来这只是他们所做的事情。目标从顶部开始，然后逐渐下降。这是很常见的。和有缺陷的。 级联（或瀑布）的特征是什么？ 这是一种自上而下的单向不可逆流，没有反馈循环，最终会冲向岩石。敏捷，创新的组织所不希望的一切。 级联模型是命令与控制思维定式的残余，其中决策仅从顶部向下流动。我们必须停止使用自上而下的类比。文字和图像功能强大，有助于塑造组织的文化。 尽管级联目标是对先前方法的一种改进，但它花费了太多时间。正如詹姆斯-哈维（James Harvey）写道： [传统模型]是自上而下的方法，通常花费太长时间才能实现对齐。直接报告通常取决于上级主管目标的完成，然后才能开始建立自己的目标计划。 我见过一些全球性公司，其中设定目标的过程需要4到6个月。这不仅浪费了大量资源，而且使员工将近半年没有明确的目标。 一定有更好的方法。 双向目标设定 正如Google的前人事运营副总裁Laszlo Bock所说的那样，他在《工作规则》一书中写道： 关于目标，学术研究与您的直觉一致：拥有目标可以提高绩效。但是，花费时间来实现公司上下的目标却没有。这花费了太多时间，而且很难确保所有目标都齐备。我们有一种基于市场的方法，随着时间的推移，我们的目标会全部收敛，因为知道了顶级OKR，其他所有人的OKR都是可见的。完全脱节的团队脱颖而出，而涉及每个人的几项重大举措很容易直接管理。到目前为止，一切都很好！
2020/4/29
articleCard.readMoreOKR新手入门指南 （第四部分）
典型的OKR系统周期 常见的OKR系统周期为： 1）在年初，公司定义了一组高级战略OKR，最好是在团队的帮助下。 重要的是要理解，没有团队的投入，高层管理人员就不应孤立地制定战略性OKR。Keith R. McFarland 在他的文章标题：您应该像构建软件一样构建战略吗？ 由于组织中各个级别的人员都会进行日常折衷，从而影响公司的战略成功，因此需要设计流程来吸收组织各个方面的想法，而不仅仅是高层管理人员。 2）执行团队然后验证公司的OKR，并从团队中收集反馈。 3）团队使用上述双向方法开发战术OKR。 4）团队映射相互依存关系，并确保与其他团队和计划保持一致。 5）团队每周签到一次，以跟踪结果和行动。 6）对于使用季度OKR的公司，通常在中期OKR审查期间在季度的中途对OKR进行审查。 7）在周期结束时，您可以快速回顾一下/吸取教训并重新开始。 进行回顾的最简单方法是 开始-停止-继续 格式。在此模型中，要求每个团队成员标识团队应做的特定事情：开始做/停止做/继续做。 对上一个周期未实现的OKR进行重新评估，以便可以将它们包含在下一个季度中，如果不再需要，可以将其丢弃。 一些公司将目标视为公司和团队随时间推移而追求的”愿景”，因此目标可能会从一个季度过渡到下一个季度。例如，诸如”使我们的客户满意”之类的目标是公司可以在多个季度中使用的目标，在每个战术周期中创建新的关键结果。 甚至随着时间的推移，某些关键结果本身也可能是相同的，只是更改了目标。在我所见过的所有公司中，几乎所有季度都有收入和净促销值等指标。但是，每个团队将用来改善这些指标的价值驱动力会随着时间而变化。 为什么您应该将OKR和薪酬分开 OKR是一种管理工具，而不是员工评估工具。因此，OKR框架的基本组成部分是将OKR与薪酬和晋升分开。 正如英特尔的安迪-格鲁夫（Andy Grove）写道： OKR不是作为绩效评估基础的法律文件，而应仅是用于确定个人表现如何的一项输入。 Google的Rick Klau写道： OKR不是员工评估的代名词。OKR与公司的目标以及每个员工如何为这些目标做出贡献有关。绩效评估（完全是评估员工在给定期间的绩效）应独立于其OKR。 这与显示老化迹象的传统模型有很大不同。Willis Towers Watson进行的一项研究表明，绩效工具的典型薪酬既不能有效地提高个人绩效，也无法对其进行奖励： 北美只有20％的雇主表示，绩效工资有效地推动了组织中更高水平的个人绩效。 公司对短期激励给予低分。只有一半的人说短期激励措施可以有效地提高个人绩效，而更少的受访者（47％）说这些激励措施可以有效地根据个人绩效来区分薪酬。 两个奖金的故事 曾经有一个组织有两个员工在同一团队中：保罗和玛丽。 保罗很聪明，专注并取得了成果。但是他受到金钱奖励的驱使，并且一直试图找出如何赚更多的钱。 玛丽也很聪明，专心，但是她为自己的成就所驱动。她相信，如果她成功了，金钱将会随之而来。 该组织使用简化的奖金公式，将目标与奖励联系起来： 奖金=ƒ(已达成目标的百分比*薪水等级) 这意味着奖金的大小是员工薪资等级和员工实现目标的百分比的函数。 然后，发生了以下情况： 保罗实现了一个轻松目标的110％，在与经理进行了数轮谈判之后，他成功地实现了目标。 玛丽达到了一个雄心勃勃的目标的80％，远远超出了公司认为可能的范围。一个真正的伸展目标。 谁应该得到更高的奖金？当然是玛丽。 但是，谁最终得到了更大的奖金？保罗 这个故事是不正当动机的经典例子。实际上，我们的奖励制度是对不当行为的奖励。 我们都是保罗和玛丽 每个人里面都有一些保罗和玛丽。您的激励系统应该对现实生活中的真实人起作用。即使您的团队充满玛丽，为什么您会拥有一个激励您不想发生的事情的系统？ 如果您要创建一种文化，以制定延伸目标为准则，则应考虑放弃针对奖金和晋升的基于公式（或紧密耦合）的模型。 有什么选择？ 另一种选择是采用一种系统，其中将目标的实现输入到绩效评估过程中，其中定义了奖金和晋升。在此模型中，奖金和目标是松散耦合的。 绩效评估不仅考虑实现目标的百分比，而且还考虑目标本身：难度和对业务的影响。将其视为体操难度分数：执行更困难的例程可以获得更多分数。 “但是这太主观了” 关于此模型的常见抱怨之一是它是”主观的”，而基于公式的模型是”客观的”。 问题在于，在流程结束时使用公式并不能使其客观。人们认为这是客观的，因为他们所看到的只是一点数学： 世界各地的几家公司（至少有时）使用即期奖金或酌情性奖金来补偿或补充奖金政策。两者都是遵循主观规则的100％任意性；
2020/4/29
articleCard.readMore关于交付价值的一点思考
本文引用了《软件开发的本质》一书的部分观点。它很好地启发了有关价值的思考，同时也是一个大胆的广告。如果你还没有这本书的话，你可以请直接从线上购买。 一、价值的特性 我们可能做的每个特性都是为了给产品增加一些价值。每个特性都需要花时间去实现。我们不知道这些特性有什么价值，也不知道实现这些特性需要多长时间。但我们仍然有可能能很好地感知应该做什么。 假设上面这些特性的高度是它们的价值，宽度是它们的代价（成本或花销）。哪一个应该先做，哪一个应该稍后做呢?这样假设很清楚，不是吗? 二、价值的增长取决于我们选择做什么 如果我们优先选择高价值、低成本的特性，而后再实现低价值、高成本的特性，这样看价值增长的差异，就是3倍与1倍的差异。而在大多数产品中，最好的创意比最差的要好几十倍，甚至更多。但是这个结果很难在页面上展示出来! 一些被推迟实现的特性看起来相当枯燥。假设我们做一些不同的，更有价值的特性，甚至是其他产品，会发生什么? 三、我们甚至可以把投资转向新的产品 最高价值的特性最先被频繁地发布，那些不值得花时间和金钱去做的特性很快就会出现，这是一件好事。我们常常可以通过投资新的产品而做得更好。 我们想做的下一个产品是什么呢?谁会对产品的变化感到消极呢?我们怎样才能使这种转变对每个人都有好处呢?我们能否专注于一个投资组合，而不是一个回报率递减的单独产品?我们能展示更多更有价值的软件吗? 最好的价值来源于小的、以价值为中心的特性，并且频繁的交付。 是的，我们可以看到小的特性可以更快地交付价值。接下来让我们考虑管理我们的项目。较小的可见结果会对管理有帮助吗？还是会给我们带来阻碍? 我们的团队呢?他们是按照这样的方式工作的吗?他们需要的人，需要的技能，需要的帮助被满足了吗?继续读下去——我们会讨论所有这些事情。 首先要记住的是，我们通过交付软件的每个特性来获得最好的结果。 你喜欢这些来自《软件开发的本质》的引用吗? 已经有一本了吗?或许你有很多的朋友和同事也需要一本呢! 作者：Ron Jeffries 译者：年志君 审校：Bob Jiang 原文链接
2020/4/29
articleCard.readMoreOKR新手入门指南 （第一部分）
什么是OKR？ OKR（目标和关键结果）是Google和其他公司使用的目标系统。这是一个简单的工具，围绕可衡量的目标进行调整和互动。 OKR：Google的目标设定方法 与传统的规划方法有何不同？ OKR经常设置，跟踪和重新评估-通常每季度一次。OKR是一个简单，快速的流程，可以吸引每个团队的观点和创造力。 在组织中建立一致性是OKR的主要好处之一。目的是确保每个人都以恒定的节奏朝着相同的方向前进，并具有明确的优先级。 OKR的最初概念来自英特尔，并传播到其他硅谷公司。Google在1999年采用了OKR。它支持Google从40名员工发展到如今的60,000多名员工。 除Google之外，其他公司也使用OKR，包括Spotify，Twitter，LinkedIn和Airbnb。 但是OKR系统不仅适用于数字公司。沃尔玛（Walmart），塔吉特（Target），《卫报》（Guardian），邓白氏（Dun and Bradstreet）以及荷兰银行（ING Bank）也正在使用OKR。 OKR的组成部分 约翰-杜尔是有史以来最成功的风险投资家之一。他的职业生涯始于英特尔，后来投资了Google和Amazon等公司。将Google引入OKR的Doerr提出了设定目标的公式： 杜尔的目标公式 我将按照_________的标准_____。 一个适当的目标必须描述您将要实现的目标以及如何衡量其目标。这里的关键词是”按…衡量”，因为衡量是使目标成为目标的要素。没有它，您就没有目标，您所拥有的只是欲望。 Doerr公式是解释OKR结构的最佳方法： 我将根据（这套关键结果）进行（客观）评估。 因此，顾名思义，OKR具有两个组成部分：目标和关键结果： 目标是您想要实现的令人难忘的定性描述。目标应该简短，鼓舞人心且引人入胜。目标应该激励和挑战团队 关键结果是一组衡量您实现目标的进度的指标。对于每个目标，您应该有一组2到5个关键结果。不仅如此，没有人会记住他们。 所有关键结果必须是定量的和可衡量的。正如Google前副总裁玛丽莎-梅耶所说： “如果没有数字，则不是关键结果。” 例子一 首先，我们需要一个目标。例如”创建令人敬畏的客户体验”。听起来不错，但是您怎么知道体验很棒呢？记住，没有度量就没有目标。 这就是为什么我们需要关键成果。我们如何衡量我们是否提供了出色的客户体验？净推荐得分（NPS）和回购率将是两个不错的选择。我们的客户对与我们打交道是否感觉很好，以至于他们会推荐我们并再次购买？ 但是，仅测量NPS和重复购买会发送错误信息。它可能会鼓励我们不惜一切代价使客户满意。因此，我们可以包括诸如客户获取成本之类的对策。我们希望让我们的客户满意，同时控制成本。 完整的示例为： 目标： 创造出色的客户体验 主要结果： 将NPS得分从X提高到Y。 将回购率从X增加到Y。 将客户获取成本保持在Z以下。 例子二 现在考虑一个希望增加数字服务参与度的团队： 目标： 使我们的客户高兴 主要结果： 将收入流失（取消）从X％降低到Y％。 将NPS得分从X增加到Y。 将每个活跃用户的平均每周访问次数从X提高到Y。 将非付费（有机）流量从X增加到Y。 将参与度（填写完整个人资料的用户）从X提高到Y。 再次具有一系列关键结果有助于创建健康，可持续的OKR。我们希望增加每周访问量，但我们希望它是有机的，而不是通过扩大营销支出来实现。 关键结果至关重要。最重要的是，它们定义了”使我们的客户高兴”的含义。第二个团队或公司可以使用具有不同关键结果的相同目标。 OKR有什么独特之处？ 没有一种使用OKR的方法，每个公司或团队都可以对其进行调整，以创建不同的版本。但是有一些核心概念： 敏捷目标 OKR不用敏捷的年度计划，而是采用了敏捷的方法。通过使用较短的目标周期，公司可以适应变化并做出响应。 简单 使用OKR很简单，而且OKR本身很容易理解。英特尔的原始模型每月设定目标，这需要轻量级的过程。 采用OKR的公司将设定目标的时间从几个月减少到几天。结果，他们将资源投入到实现目标而不是设定目标上。 透明度 OKR的主要目的是在组织中建立一致性。为此，OKR对所有公司级别都是公开的-每个人都可以访问其他人的OKR。CEO的OKR通常可以在Intranet上找到。 嵌套节奏 OKR理解策略和战术具有不同的自然节奏，因为后者的变化趋势往往更快。为了解决这个问题，OKR采用了不同的节奏： 具有公司高层，长期OKR的战略节奏（通常为年度）。 团队具有短期OKR的战术节奏（通常每季度一次）。 OKR跟踪结果和计划的操作节奏（通常每周一次）。 双向目标设定 传统的自上而下的级联模型花费太多时间，并且没有增加价值。正如Google的前人事运营副总裁Laszlo Bock所说的那样，他在《工作规则》一书中写道：
2020/4/28
articleCard.readMore管理远程团队的5个必备要点
如果您突然要管理一个虚拟团队-你们中的许多人-这些做法将帮助您进行过渡 远程人才计划负责人在所有人突然从家里工作之前，远程工作是一个热门话题。根据我们进行的内部调查，接受调查的Atlassian中有95％愿意改变工作方式以实现远程的工作。 但是，我们大多数人仍然对在家工作及其特征尚不陌生。这不仅是弹性工作时间，不是您的日程安排中的在家工作，或者是为住在农村州的队友提供住宿。现在，尤其是整个团队都在远程工作。这意味着新的实践（或对常规实践的修改），新的工具和新的交流方式。为了使所有这些工作顺利进行，团队负责人要承担更多责任。管理人员定下基调。无论您的团队是一起坐在一个房间里并挤在一起，还是在Zoom会议中实际上是分布并挤在一起，都是如此。 但是要振作起来。尽管管理虚拟团队可能对您（以及许多其他人）来说是新的，但其他人已经有一段时间了。以下是对这些远程领导者有所帮助的一些实践，列出了管理和支持远程团队的实用方法。这些轶事和故事，关于什么是行得通的，什么是行不通的，这些将有助于您作为新远程船的船长在这些奇特的水域中航行。 管理虚拟团队的5个基本技巧 1.过度沟通 大多数领导者心中的一个大问题：远程领导团队和亲自领导团队的*主要*区别是什么？好吧，不只是*一个*区别。但是，可以肯定地说，您首先应该关注的是沟通，以及每个人在远程工作时通信是如何改变的。 在”正常的工作”中，许多决定是通过走廊交谈或午餐时间做出的。当这种临时信息共享没有发生时，您必须以某种方式替换它。首先要做好过度沟通。对于团队中的某人而言，根据新的决定，任务的状态或最近的更新，不同步就太容易了。无论如何都会发生，对吧？试想一下，当您的整个团队都在远程工作时，事情会跌落的裂缝。不仅仅是这些偶然的联系机会减少了，而且熟悉的团队信息交换也被完全破坏了。 因此，过度沟通。练习一下。使用Slack消息，@提及和电子邮件可以使所有人保持联系，即使您认为自己在重复。询问他们是否了解某些事情，即使您确定他们确实知道。请记住，如果是在小组互动中，则可能是Zoom呼叫中的其他人因为您询问或重复信息而不知道并了解到了该信息。重复一些内容以保持清晰无害，并且可以立即解决一些问题。 小提示 默认情况下，尽可能通过1:1消息进行团队沟通，并创建共享页面（如Trello面板或Confluence页面）以记下这段时间内的交流做法，以便整个团队可以关注和修改。 2.透明地工作 当然，还有另一个大问题，尤其是对于经理来说：您如何知道您的团队在工作？他们有生产力吗？ “我对100％远程访问的最初反应是每天通过Zoom进行登录，并坦率地安排了更多会议，” Atlassian PMM组的Claire Drumond说。”我意识到，我的团队在证明他们的工作压力方面与在确保他们没有压力的压力一样大！我们仍在继续完善自己的礼节和学习，但是如果没有信任和诚实，您将无法改善事情。建立对技术的信任与在工作时间空闲的人无关，这是要设定明确的期望和沟通。” 从很多方面来说，如果您真的聘请了合适的人，则不必为此担心。您应该相信您的团队，相信他们是您雇用的成人专业人士。但这是一个公平的问题，帮助回答这一问题的一种方法是查看您的工具。在Atlassian，我们使用Trello，Confluence，Jira，Slack，Zoom和许多其他工具。但是，无论使用哪种工具，都与您如何使用它们以及对您在做什么和何时进行透明化以及与团队和利益相关者共享所有有关的信息。 如果您正在寻找确保这种基本信息共享发生的方法，并且正在讨论项目和里程碑，那么可以尝试以下方法： 考虑频繁地更新Slack状态。要针对自己和团队，养成具体且一致的习惯。”深入工作”，”下午1点的午饭时间”和”散步”确实很不错。 @提醒多人。如果您不特别针对某人，请不要以为别人会看到评论或更新。重复使用某人的名字以确保其知情并没有什么害处。 使用共享的Google日历，并保持更新。一致的日历非常适合了解每个人的工作（无论是工作还是非工作生活）。 尝试站立会议。这些简短的团队会议可能非常有效。您可以更改一天中的时间，频率和名称。一些团队从YTB开始他们的一天-他们昨天做了什么，今天他们正在做什么，以及任何阻碍者。团结一致是一种一致的做法，当每个人都处于远程状态时尤其有效。 简而言之，请开发实践以帮助您的团队保持联系并提供有关正在发生的事情以及在哪里可以找到信息以了解正在发生的事情的更新。您不必担心人们在做什么，但是这将使您和他们的头脑轻松，为每个人提供共享更新的方式。 3.建立团队的远程工作基本规则 当事情是新的和不同的时，很难知道如何设定期望。像以前一样？如果远程团队不一样，怎么办？ 简单的答案是：确保团队中的每个人都在同一页面上（大家的理解是一致的）。分组讨论，并得到大家的投入。在家工作对许多人来说是新事物，在当今不确定的情况下，它尤其独特。家里有孩子和其他家庭成员，新的时间表和节奏，无数的压力和担忧。必须考虑所有因素。在就您的团队需要以及您作为经理的需要和需要进行的这些坦率的交谈之后，请考虑以下提示： 在页面上记录所有内容，以帮助确保每个人都在同一页面上。这意味着一切：方法，角色和责任，行动项目，期望，关键决策等。 花时间与团队讨论您的沟通渠道和工具以及如何使用它们，包括预期的响应时间。 讨论如何在共享工作上保持一致，以及如何在该工作上进行协作。换句话说，建立您的分享习惯。 使用不同类型的会议-1：1，小组会议，整个团队-提供反馈并养成熟悉的习惯。 您正在做的是创建剧本。您正在建立有关团队运作方式以及每个成员的期望的规则。 4.检查人们的个人情况 您的团队表现如何？问，然后再问。这不仅意味着项目，还意味着人们的行为*方式*。首先，要为您的团队创造一个安全的空间来分享思想和感受。在如此空前而艰难的时期，这至关重要。作为经理，请尝试找出每个人的*实际情况*。寻找并提供必要的时间和空间进行私人交谈。 偏远的人经常遭受过度劳累。工作与生活之间的界限模糊，并适应不同的时区，通常很难”拔出”插头。所有这些都会损害人们的福祉。更不用说与远程工作相关的孤独感，更难以”看到”职业倦怠或与远程团队成员识别孤独感。 您必须经常检查，并真正证明您对团队的承诺。如果他们在截止日期前需要一些额外的时间，则要灵活一些。如果最近几天团队成员似乎还没有出现，请检查一下。以下是一些开放式问题的想法，这些问题有助于建立安全的空间： 你有什么感觉？ 您的工作量如何？ 你的倦怠程度怎么样？ 什么是最重要的？ 你的世界怎么样？ 你的工作怎么样？ 5.建立有趣的远程团队礼仪 在完全远程的同时保持团队的社交联系与以往一样重要。但是，您如何远程进行呢？ 为了使团队保持一致，Atlassian创意总监Leah Pincsak发现了这样一个瑰宝：”打包您的几周社交活动，使其成为可选项，并且如果没有人出现，请不要感到冒犯。” 无论情况如何，团队之间的社交联系都至关重要。远程团队可以从团队社交礼仪中受益匪浅，但是需要有意识地培养他们。换句话说，不要强制虚拟的欢乐时光，只能像喝酒那样像例会。正如Leah所了解的那样，要使社交活动正常运作并感觉正确，它们必须是可选的。没有这种义务的感觉，他们为非强迫联系保持了必要的随意性和自愿性。 要考虑的其他社会观念： 设置社交Slack渠道，以在各种主题上保持联系。通常被称为”虚拟水冷却器”，创建一个聊天或分享特定主题的地方。 设置虚拟咖啡，午餐或欢乐时光。指定的时间在一起很漫长。 尝试像破冰船一样通过快速的个人登记开始每个团队会议。 一起玩虚拟游戏，这可能是一个很棒的结合体验。同样，请确保这些活动始终是自愿的，并保持这种感觉。鉴于目前情况如此之多，要求父母在漫长的一天之后而不是与孩子们一起度过”玩乐时间”是一个很大的要求。 查看一些虚拟团队建设活动，以探索更多想法。 像任何东西一样，这需要一些习惯。但是，您已经建立了可以模仿的虚拟团队管理实践和习惯。是的，这与在更”传统”的环境中一起工作并不相同。但是，您只需付出一点点努力，就可以比以前更好（甚至在某些情况下甚至更好）一起工作。 作者： NIKKI BELLINGTON 译者： Bob Jiang
2020/4/27
articleCard.readMoreIPD下的敏捷实践 | 敏捷家分享006
内容来源：敏捷+社区线上直播006期，《IPD下的敏捷实践》分享实录 分享者：京东单冰 关注本公众号回复”IPD”即可获取本次分享的视频回放、下载PPT 大家好，非常有幸能够和Bob相约一起，给大家做这一次的分享。我现在就开始了，在京东智联云变革的这种形势之下，我们从去年开始接触到了IPD。之前认识我的伙伴们都知道我在京东做敏捷转型这方面的事情。 先自我介绍一下，我在京东算时间比较长了，之前在京东零售现在在京东智联云，之前我们叫AI，今年AI和云合并叫智联云，我正在负责京东智联云产品研发BP的项目管理团队。我们团队会负责敏捷转型等管理工作，同样也会带团队做管理变革、做 IPD流程导入，并且计划把敏捷和IPD进行一个完美的融合，希望去拉动产品线做融合。 对于我自己来讲，参与全国敏捷社区的活动组织，做过敏捷之旅、Tid大会、和多次全球技术周的分享嘉宾。非常愿意跟大家去一起分享在敏捷落地中的一些感受。很多同学其实之前在问我说你们在做IPD，这个跟敏捷是不是有一些冲突啊？会不会是我们又回到大的瀑布了？所以今天这个分享也会跟大家去做一些探讨和解读。 今天我们大概会分三个部分去给大家做一个分享： 第一个部分，从整体业务企业敏捷生态圈去考虑怎么样使敏捷联动市场，直接引导市场价值。 第二个部分，讲讲如何和做IPD，这是今天跟大家探讨的一个重点部分，如何用敏捷+IPD拉动市场。 第三个部分，敏捷+IPD环境下，敏捷教练项目经理应该在什么位置？怎么样去自我变革？怎么样去引导团队？ 第一部分，启动篇 业务级敏捷系统生态圈，市场导向直击价值 为什么要做这件事情呢？在市场的引导下，一步一步的去验证敏捷，去引导团队。变革就是因为在不确定的这种环境下，会面临很多不确定的事情。在团队变革的过程中，它也会新陈代谢的。在市场环境里，公司会面对很多严峻的问题。 现状问题是什么？面对这么大一个成熟团队，面对两个成熟团队的融合，你会看到他们的问题到底在哪？首先从问题出发，方向就是解决这些问题。 查看原文获取更多材料
2020/4/26
articleCard.readMore敏捷（组织）转型的6个准备条件
敏捷转型非常复杂。成功有巨大的好处，但不能保证成功。客户所钟爱的生产力，创新和更高品质的产品或服务的提升，可以使转型组织的挑战变得非常值得。 与任何工作一样，在开始之前进行正确的准备将大大改善结果。 作为Scrum的教练和培训师，多年来，我与各种各样的客户合作，从金融到农业，从媒体到制造业，并且不断发现6个关键要素可以使您的转型正确地开始。 1. 建立合适的团队 敏捷转型可能是组织上的，但它是建立在强大的Scrum团队的基础上的，这就是为什么您需要拥有”合适的团队”的原因，但是在当前的偏远地区，招聘比以往任何时候都更加困难。让您的团队参与招聘过程至关重要。文化适应对建立强大团队和技能组都同样重要。视频聊天是虚拟世界中重要的面试工具。这使团队有机会与候选人见面，并使候选人看到团队互动。 每个团队都应该具备从开始到交付工作的所有必要技能，但是团队也应该足够小以确保轻松协作（《 Scrum指南》本身建议三到九个人）。这消除了跨团队或跨部门的依赖性。最大的时间浪费是在等待其他团队或经理的”批准”或”答案”。这些延迟开始增加，使团队没有足够的时间来实现他们的目标，这正在缩小！ 团队需要明确的目标和方向，以供他们开发产品。这种共同的愿景有助于团队感觉相关并与更广泛的企业联系。一旦有了明确的指示，团队就必须拥有”方法”。他们必须有权组织自己，以构建自己认为合适的高质量作品。 领导力将使团队有责任按时，按预算完成这项工作，还将寻求使他们能够采取行动，而无需不断的检查和批准。达到这种平衡至关重要。而且，这将有助于塑造敏捷转型的组织文化。 2. 从第一天开始就有好的指标 您怎么知道您的转型是否有效？这是一个重要的问题，在敏捷转型已经开始之前，这常常被忽略。 通过尽早设置这些指标，您可以从第一天开始进行检查和调整，并极大地增加了成功的机会。 在开始新的冒险之旅之前，团队需要知道成功会是什么样。管理层和团队都需要就我们将要采取的措施达成共识，以确认我们的新工作方式确实有效。团队和经理都必须明确期望。 期望对于与团队合作的每个人必须透明。 “您为什么开始这一转型旅程？” 该问题的答案是什么定义了转型的目标，并最终定义了工作的成功。清晰的愿景提供了目标。目标是团队的主要动机（Dan Pink，*Drive*，2011年，中文版《驱动力》），并确保从领导者到产品负责人再到团队成员的每个人都为实现这一至关重要的共同愿景而努力。 团队幸福感是所有企业特别重要的一项指标，尤其是在我们正在一个偏僻的工作环境进行敏捷转型。随着社交选择变得越来越有限，我们必须密切关注幸福。幸福是主要指标；当团队的幸福感突然下降时，质量和速度往往随之而来。 3. 专注于产品而非项目 组织通常将精力集中在他们的”下一个大项目”上，但是，如果您退后一步，您会发现这种思想的潜在缺陷。项目是一项短暂的工作，将”紧急”放在优先位置。但是，优秀的团队实际上是长期存在的。 一个项目可能代表着全新的事物。或者它可能只是已经存在的新事物。但是产品是持续交付的服务或功能，是公司使命的核心。 了解这两者之间的区别是关键。敏捷组织特别了解他们的产品是什么，以及他们的项目适合企业的整体情况。他们对自己的价值流有清晰的了解，因此可以开始围绕传递价值和发展这些价值流来构建其转型。 稳定的团队会更成功，这是建立在团队协作并学习如何协作的基础上的。它随着时间的流逝而发生。 4. 选择合适的产品负责人 产品负责人（PO）是*至关重要的角色* ，是团队和敏捷转型的关键。产品负责人应该激励他们的团队。在寻找一个好的产品负责人时，要寻找一个即使使团队遥遥领先，也能使团队对其所做的工作以及他们的产品*可能*感到兴奋的人。产品负责人还必须对团队有强烈的信任，他们会弄清楚如何单独交付PO所要求的。最重要的是，在为您的团队寻找PO时，请找一个善于倾听的人。倾听是强大领导力的核心。 专门的产品负责人是鼓舞人心的领导者。她拥有团队目标的愿景；团队需要做什么以及为什么需要这样做。 他们必须对自己的市场及其当前趋势具有深刻的见解和认识。为了实现这一目标，她必须花大量的时间从客户和利益相关者那里获得重要的反馈，然后利用这一见解来塑造与团队共享的愿景。阐明愿景使团队成员具有目的感以及与企业目标和使命的联系。这就是为什么我们说PO拥有”什么”（指的是方向）。 最后，这是一项全职工作。 产品负责人不能只专注于该角色。他们不能再有”日常工作”。一个已经有另一份工作的PO对两者都不利，并降低了整个企业的价值。许多组织都迷失了这一步。开始转型时，请不要犯此错误。每个团队一个PO并不是成功的秘诀，但多个团队的一个PO无疑是灾难的秘诀。 译者注：这里Bob并不同意原文的观点。多个团队（前提是一个产品）一个PO是很合理的。具体细节回头再展开一篇文章。 5. 选择合适的Scrum Master Scrum Master必须是服务型领导。 那么到底是什么意思呢？ Scrum Master不仅可以促进Scrum活动的开展，而且还是值得信赖的团队成员，致力于为团队提供支持和”服务”。这包括在Scrum上指导团队和产品负责人，并消除可能会使团队减速的任何障碍或问题。 Scrum Master角色需要高水平的情商，才能了解团队的动态并保持进度。Scrum Master准备好并且愿意与那些”不舒服的”对话来帮助团队克服在学习成为团队中自然产生的挑战。一起感到不舒服，一起感到舒适。 Scrum Master需要衡量他们的团队是否满意。研究清楚地表明，快乐的团队可以更好、更快地完成工作，并能提供更高质量的工作。在2012年1月至2月的《哈佛商业评论》中，他们将整本杂志的重点放在幸福上。他们发现的是： ”……我们发现，使员工感到幸福的唯一途径也是使股东受益，这是因为出色完成一项重要工作所带来的成就感。我们不仅要使员工”快乐”，而且要通过帮助他们成就伟大的事情来实现。简而言之，我们应该通过帮助员工赢得客户的热情拥护，赢得员工对公司的使命和成功的热情拥护。” （HBR博客Rob Markey，2012年1月7日） Scrum Mastery是我最爱的角色。在远程工作的世界中，Scrum Master的工作要困难得多。在远程工作的团队中，您的Scrum Master将是帮助指导团队如何共同工作和保持一致的人。她将通过制定团队工作协议，然后让团队负责达成他们达成的协议来做到这一点。在我们合作的世界仍然未知，建立、执行和重新评估该协议对于建立强大的团队动力至关重要。 Scrum Masters还可以帮助团队专注于工作与生活的平衡。众所周知，现在远比在办公室工作要困难得多。这需要有人让每个人都对自己的真实感受保持诚实，有时，认真研究我们的实际举动是我们自己做不到的。Scrum Master必须成为提醒我们的指南，以提醒我们如何在这个不确定的工作环境中照顾自己。 6. 指导与管理 甚至在为敏捷或数字化转型启动第一支团队之前，您都需要获得领导的支持。最重要的是，管理者需要成为指导者。 任何成功的转型都涉及思维方式的重大转变。没有这种转变，您的组织就有使用Scrum术语（”仅以名称命名敏捷”）的危险，而实际上并没有改变您的工作方式。 在一个转型的组织中，领导力的目的是定义和共享组织的愿景，消除使团队变慢的事情，并指导和授权他人。 管理工作；带领人。随着世界变得越来越疏远，这变得更加真实。事实是，许多人喜欢生活中的自治和授权感。通常，传统的”人事管理”会感到束手无策，尤其是对于像我这样的人而言，他们立即拒绝被告知天性该做什么。领导力是关于赋予人们权力，提供心理安全和服务型的领导力，但同时也意味着要使人们对自己做出的选择的结果负责。我们必须能够相信我们的团队不需要持续的监控。他们真正在乎产生卓越的结果。
2020/4/26
articleCard.readMore什么时候不用测试驱动开发（TDD）
我什么时候不使用TDD？ Alex Bunardzic一直是有关TDD及其反对者的 Twitter 话题中的一员。他的担忧之一是TDD的支持者同意TDD并不总是合适的，但没有说什么时候不用TDD。让我们探索一下。 亚历克斯的担忧似乎在于他正试图让组织中的人员使用TDD，其中许多人提出了异议。这些异议之一是，甚至专家都说他们并不总是使用TDD，所以我们为什么要在这里使用TDD。 现在，如果您接受销售培训0^，那么您将要教的一件事是如何处理异议。第一项也是最强大的技术是忽略它们。在销售中，您可能会继续提出反对意见，这就是为什么我们很多人讨厌被出售的原因之一。 我没有卖任何东西，但似乎Alex负责在他的公司中销售TDD，所以我们可能有不同的担忧。我在写和讲授思想上的关注是可以理解的。我很乐意将决定权交给听众。如果我每月都有这么多TDD销售的配额，我可能会有所不同。 尽管如此，我确实知道有些情况下我通常不使用TDD，并且我或多或少乐于谈论它们。或多或少是因为TDD主题似乎不断地深入我的灵魂。无论如何，这里是： 我什么时候不用TDD？ 让我数一数：我*有时*不用TDD的… 当手头没有合适的TDD工具时； 当我不知道如何测试某事时； 当输出本质上是可见时（可视化）； 当程序是一个简单的，会扔掉的。 让我们通过示例进一步探讨其中的每一个情况。 当没有像样的测试工具可以立即使用时，我通常不用TDD。 一个例子是我iPad上的Codea Lua。它没有附带TDD工具，而且很长一段时间没有可用的工具。我很喜欢写一个玩玩，因为在Lua中反思很有趣，但从未真正得出我喜欢的东西。 然后出现了CodeaUnit，它工作得非常好，我最近在示例TDD会话中使用了它。但是请参阅以下部分。 另一个示例是Second Life的脚本语言LSL。该语言非常初级，不包含反射功能，这在您尝试生成一个体面的TDD框架时非常重要。如果没有可用的工具，则我用TDD的频率将比理想情况低。 但是请注意：缺少一个不错的工具并不是不使用TDD的很好理由。通常，我在Lua或LSL上的开发所花的时间要比遵循TDD学科所需的时间长。我怎么知道？我对使用TDD和不使用TDD时会发生的事情非常有经验，因此我很容易认识到缺少测试会伤害我的情况。 最好的迹象是调试会话需要更多的时间。这总是表明更多测试时我‘会做得更好。 如果工具不易使用，您是否应该考虑不使用TDD？ 我认为这不是很好的理由。几乎可以肯定的是，无论您使用哪种语言，都可以使用一个很好的TDD工具。对我来说，如果是只写一些小小的一次性程序的人，寻找和学习该工具的投资*可能*不值得。您正在专业地工作。对于您来说，投资可能是值得的。 很可能，这对我来说是值得的。在没有TDD的情况下工作会使我更经常地进入调试模式。即使对于我的小型项目，TDD的价值也可能存在。我将自己不这样做的原因归咎于懒惰，说实话而不是出于智慧。 当输出本质上是可见（可视化）时，我通常不进行测试。 在Codea / Lua中，人们经常编写一些代码在屏幕上绘制运动对象。在《第二人生》中，我经常编写脚本来在虚拟世界中移动事物。尽管这些脚本中的某些部分可能会从TDD中受益，但总会有一些-其主要功能使我不知道如何有效地使用TDD。 让我们举两个例子。 想象一下，我想在iPad屏幕上绘制一个蒸汽引擎。该图片的一部分将是引擎驱动轮，该驱动轮会随着火车的移动而旋转。推杆安装在该轮的半径中间附近。该推杆的轮端绕转0^左右。该杆的另一端在连接到蒸汽活塞的另一根水平杆的推动下水平地前后移动，该水平杆只是来回运动。 我们的任务是在轮子旋转时针对每个角度计算推杆的位置。为了弄清楚该如何做，我绘制了一些草图并做了一些几何处理（通常使用直角三角形），直到我弄清楚了在每个方向盘上的远端在哪个位置。 显然，当车轮为零时，推杆完全远离车轮，其端点为l + r，其中r为推杆圆的半径，l为杆的长度，假设车轮位于零位置。 当车轮处于180度时，终点将在l-r处。当车轮位于90或270时，终点将为…sqrt（l ^ 2-r ^ 2）。同时，如果角度为θ，则起点为 rotBy（θ）。 大概。多一点的几何使我相信终点是sqrt(l*l - y*y) - x，其中x和y是起点的相对坐标。 也许，有一种更好的方法来计算终点。它一定是某种 sin或cos (正弦或余弦)功能或类似的东西。但是这种方法很好用，因为我们有能力在两点之间画一条线。 所以我只是编写了代码，看起来像这样，没有进行大量清理： -- Loco function setup() theta = 0 -- degrees deltaTheta = 1 origin = vec2(600,600) radius = 200 rodRadius = radius/2 rodLength = 500 end function draw() background(40, 40, 50) strokeWidth(5) drawWheel() drawRod() theta = theta + deltaTheta end function radians(angleInDegrees) return angleInDegrees*math.
2020/4/24
articleCard.readMore驱动组织演进的心智模式
为什么初创公司通常是充满活力的网络结构，度过初创阶段则通常会成长为官僚化的层级结构？这里简单探讨两个驱动因素，如下图中左侧悬臂（1,5）所示。 图1: 组织复杂度为何增加 第一个驱动因素是领导者对专业化效率的期望。度过初创阶段之后的一个倾向是为效率而优化，以尽可能收割其成功产品收益。提高效率的传统做法是细化分工，从创业时期的人人都是全能战士，转向"专业的人做专业的事"，如图中B1环路（2-3-4-9-2）所示：专业化效率提升压力(2)导致分工细化，分工细化使得专业化效率提升，专业化效率提升使得专业领域的产出提升，于是压力得以缓解。此动态背后的领导者心智模式是：细化分工有利于效率提升、产出增加。 然而分工细致程度同时也带来了整合成本的增加（包括分工产生的等待浪费和集成投入）。这至少部分抵消了专业区域产出导致的总产出增加。 （分工细致程度导致的专业化效率提升还受分工导致的依赖制约，为简化，图中不表达）。 第二个驱动因素是领导者对管控程度的期望。领导者的控制倾向带来增强管控程度的压力。这种压力会使分工细致程度增加，以增加角色职责清晰度，从而增强管控程度，缓解管控压力（环路6-3-7-8-6）。此动态背后的领导者心智模式是：明确的职责分工可以带来对组织和员工的有效掌控。 公司成长过程中，这两个驱动因素往往导致分工细致程度增加，然而分工细致程度的增加又带来一系列其他后果。分工细化会导致部门增加，进而导致组织层级增长，应变能力下降（3-15-16）。同时分工还会导致组织壁垒产生（3-12）。组织壁垒有促进人员增长的倾向（地盘意识以及流动性降低所致），而人员增长又容易进一步强化组织壁垒（软件开发为例，模块所有团队有使模块变复杂的倾向）。 组织壁垒的产生和应变能力的下降都导致组织更难把握市场上的机会，于是创新能力下降，这在更长的时间里导致总产出下降（13-10），组织走向下坡路。 由以上分析可知，组织复杂程度的增加有其内部原因，有些原因与领导者的心智模式相关而非价值驱动。而从精益观念来看，如果把组织的目标定位为为客户创造价值，那么组织的复杂性往往是超出必要的。所以，转型中常常有"简化组织"的呼声。 组织应变和创新能力的提升，有赖于领导者的心智模式升级。如果组织创新能力乃至总产出的下降不能触及领导者的心智模式，那么转型容易头痛医头脚痛医脚，难能成功。只有领导者理解了所面临问题的根源，才可能从管控型组织转向赋能型组织，并纠正对专业化效率的片面追求，使系统动态发生根本转变 – 如下图中上下两条红线。 图二：组织转型的心智基础 <感谢Paulino Kok老师的洞见对此文的贡献> 马林胜/20200420
2020/4/24
articleCard.readMore敏捷与OKR实践（如何让OKR与敏捷计划共存）
僵化的详细长期计划（根据消耗的预算跟踪进度）正在敏捷组织中迅速成为对过去的褪色怀旧记忆，这由预测和非静态路线图代替。定期在这些可视化文件前聚会，您将能够学习、共享并触发重要的对话，解决依赖性并邀请服务型领导的行为。使您的OKR和预测计划共存！ 在这个博客中，我想给出带有可视化示例以及伴随的重复仪式。可视化和伴随的仪式可以共享进度，并确保持续解决和减轻障碍和依赖性。它还将预测变成对话（与被视为承诺的项目计划中捕获的固定估计相反）。 参与团队回答的核心问题是： 敲黑板 - 划重点（译者注） “您是否有信心在本季度末之前完成关键结果？” 你可能还喜欢 Google OKR小册子 如果您不熟悉OKR，目标和关键结果的概念，则可以将目标视为”让我们对这一领域/问题/需求加倍研究”，而关键结果则视为”让我们完成这一特定影响/结果/目标/交付成果”这将推动我们朝着目标迈进。” 对于每个季度，目标数量通常限制为3-5。每个目标依次具有3-5个关键结果。常见的指导原则是，平均而言，您应该以关键结果的70％成功，即以30％失败，这是正常的并且可以接受。该准则可确保我们设定大胆的目标，并避免安全起见。为什么？好吧，如果我们惩罚成功率不到100％的事情，我们最终将优化军阀制度。 OKR白板站立会议 当2017年重新引入OKR时，我曾在Spotify担任敏捷教练。我所工作的部落（认为半自治部门）不希望OKR成为PowerPoint中的静态幻灯片，而该幻灯片很快就被人们遗忘了，但是在生活我们可以随时”计划”，以找出如何互相帮助。 与其以数字演示形式总结部落的集体协作的OKR，我们将它们（OKR）写在一块大白板上，该白板在所有团队旁边的走廊上非常醒目。每两周一次，我们进行OKR白板的站立会议。希望加入的每个人都受到欢迎，但我们要求每个团队（八个团队）至少有两名代表参加。 会议的例行很简单。我们走上了白板，一次实现了一个目标。对于每个目标，我们都会大声读出关键结果的措辞。提供该关键成果的工作团队简短地分享了进展并宣布了他们的信心水平。会议持续了15至25分钟。 置信度 对于每个关键结果，相关团队都回答了以下问题： “您是否有信心在本季度末之前完成关键结果？” 绿色自信的笑脸 –完全自信这会发生。我们可以准备市场营销活动。 橙色担忧的笑脸 –我们可能做不到，应该提醒利益相关者。 红色悲伤的笑脸 –没办法。这不会在本季度内发生。不过，我们仍在努力。 检查 –完成。已交付。做完了。 停止 –我们已停止进行此工作（…由于优先级的改变或关键结果本身已变得无关紧要）。 每个关键结果下方都有6-7个框（取决于该季度中发生了多少个两周的周期），每个OKR白板站立会议都用掉一个框。当我们进行第三次站立时，我们填写了第三个方框，依此类推。这种方法使我们对我们的信心水平有了历史的认识。 如果有几个团队提供相同的关键结果，那么他们每个人都分享他们的进度和信心水平。但是，最悲观的置信度是框中显示的置信度。 提供关键结果的团队名称以方框下方的小文字表示。 实际上，我们有第六个符号-？问号表示”我们还不知道”。有时事实证明这是现实，他们真的不知道。但是对我来说那很奇怪。如果团队不确定自己是否有决心在OKR周期内实现目标，那么如何使团队”致力于”关键结果？但是事实证明它很有用，因此我们使用了它。 关键对话触发器 但是，重要的不是信心笑脸本身的更新-重要的事件是当笑脸的颜色从上次OKR白板站立起改变了颜色。 这些变化是重要对话的关键触发因素。绿色的笑脸变成橙色或红色的笑脸时，我们暂停下来，直到我们共同弄清楚如何采取行动后才继续进行讨论。房间里谁能帮忙？会议室中的谁可以将需要帮助的团队与可以帮助的人联系起来？我们需要提醒利益相关者吗？谁提醒利益相关者？要改变置信水平吗，需要做什么？等等。 仅在决定了至少一项有力措施（有可能推动我们前进）之后，我们才进行下一个关键结果。 即使每个团队每天都尽自己最大的努力来减轻障碍和解决依赖性，但OKR白板站立会议提供了一个反复出现的机会，可以将问题升级为需要扩大支持的朋友和领导者组织。 庆祝完成 当有人宣布他们完成”关键结果”并在框中打勾时，我们显然以雷鸣般的掌声庆祝。 服务型领导的机会 最初，一名敏捷教练协助OKR白板站起来。在前几次的站会中，三个部落首领都没有找到时间来参加。但是在第四次站会，其中一个部落首领加入了。 在几分钟之内，我相信他意识到这是一次千载难逢的良机，可以阅读所有团队的脉搏，对进度进行汇总并提供有益的服务型领导行为。他可以提供建议（在被问到时），为团队面临艰难的选择时提出前进的道路，并由于他或她的广泛网络而提供帮助，将需要的团队与利益相关者和组织的其他部门联系起来。 下一次OKR白板站立会议，所有部落首领都作为观察员参加了会议，准备在被要求时提供帮助和支持。很快他们甚至轮流为仪式本身提供帮助。 OKR白板审查会议 当季度结束后，我们聚集在一起参加OKR白板审查会议。我们回顾了已完成的关键结果，并讨论了未完成的结果。我们能学到什么？在下一个OKR周期中，我们可以带些什么？我们如何改善可视化和OKR板站立状态？ 完成百分比 在第二季度，我们运行OKR白板站立会议，我们添加了一个方面来尝试使进度更新更加完整。对于每个关键结果，相关团队不仅回答他们的信心如何，而且还估计到目前为止他们已经完成了多少工作。（译者注：这个百分比慎重加） 我们为什么要这样做？好吧，我们觉得我们缺少故事的一部分。我们了解到，有时即使有些团队只是猜测自己已经完成了10％的工作，他们还是感到超级自信。有时，即使90％的工作都完成了，团队也感到非常悲观。在某些情况下，这是非常有用的信息。 组织内传播 当下一个OKR周期的时候，我们进行OKR白板后续行动的方式已在内部传播。令我们感到惊喜的是，几个部落抄袭了我们的方法。 当某种东西传播并在内部进行时，这是工具/技术/方法有用且有价值的最好”证明”。 可能的变化 如果这种方法对您有所启发，但您在团队或部门中未使用OKR，则此方法有许多变体，仍将静态预测转换为持续对话，从而触发重要对话。 预测扑克计划 如果假设我们正在处理解决一系列特定问题或完成功能之前无法交付产品，那么我们可以要求团队成员逐个猜测 “多少周/每次冲刺可以完成我们需要达到X？”通过在便利贴上写下他们的猜测。 删除最悲观和最乐观的投票，并在白板上写下剩余的范围。如果估计范围不会每周减少一周，那么您就有机会讨论可能采取的措施或缓解措施。 截止日期置信度 有时我们需要应付一个固定的期限。也许我们的机会窗口有限，或者也许我们必须在特定日期之前满足法律要求（例如GDRP）。然后我们可以问团队“我们在日期Z之前完成X的信心如何？” 可以用五个手指进行投票。一根手指代表超级悲观，五根手指超级乐观。三根手指可能意味着紧张。如果信心没有每周增加一次，我们将讨论需要做的事情或摆在我们面前的选择。 版本的猜测 一些团队会持续交付，但仍需要与利益相关者和客户沟通进度和期望。他们从产品待办列表中拉取工作加入到Sprint中。 可视化预测的方法是在Backlog中添加两行（例如，使用胶带）。 每个Sprint Review团队的成员都会问自己两个问题： “我们对在接下来的四个冲刺中交付多少产品列表条目充满信心？” “在接下来的四个冲刺中，我们还能提供多少呢？” 绘制一条绿线以可视化我们有信心我们将完成产品列表的工作。绘制红线以可视化乐观范围。
2020/4/23
articleCard.readMore重新审视故事点
我常说我可能发明了故事点，如果真是这样，现在我会感到很抱歉。让我们一起来探索我现在对故事点的思考。至少有一个人对我所想的很感兴趣。 – Ron Jeffries 当然，故事是极限编程的思想，不是Scrum的。不知何故，Scrum践行者接受了这个理念。尽管在Scrum官方指南中有关待办事项的内容，将待办事项作为用户故事是一种普遍的Scrum实践。 至少在某种程度上来说，他们是对的。我已经在其他地方写了关于故事的常规用法，正如它应该被写下来一样。在这里，我们将讨论的是”故事点”。 在极限编程中，故事最初是用来估算时间的：实现故事需要花费的时间。紧接着我们来谈谈”理想天数”，它是用来非正式地描述如果别人让你尽自己最大努力单独完成故事需花费的时长。我们用理想的天数乘于一个”负载因子”转换得到实际需要的时间。负载因子通常是3（3天才能完成一个理想天数的工作量）。 我们刚谈到用天数来估算，经常是把”理想”抛开。这将导致的结果是我们的老板很疑惑，怎么是要花费3天来完成本来1天就可以完成的任务，又或者说，为什么我们不能用3周来完成50”天”的工作。 我记得，我们开始称”理想天数”只是”点”。所以一个故事应该用3个点来估算，这就意味着这个故事需要花费大概9天来我完成。总之，我们确实也是只用点来决定多少工作进入一个迭代，所以如果我们说大概20个点，没人会反对。 我可能已提出改名字的建议。如果我真这样做了，现在会感到抱歉。从给我的同事西蒙的电子邮件中，有一些关于目前我对这个话题的想法，他问到： 你真的后悔发明了故事点，或者你只是简单谴责当他们做相关度量时，没有正确理解而导致滥用吗？ 我答道： 我当然谴责他们滥用； 我认为使用故事点来预测”我们将什么时候完成”充其量是个无力的想法； 我觉得跟踪实际与估算的比较充其量是浪费； 我觉得比较团队的估算质量或速率是危险的。 让我们更深入一点。 实际上，一些用来做”敏捷”的方法，以更容易计划的名义，推荐给各团队规范化用户故事点。这表面上看起来非常合乎情理，却太容易掉进团队比较的陷阱，组织也是经常这样做的。 比较 首先，即使他们看起来很像，每个团队都有自己的技能和特定工作环境。所以如果他们看两个貌似一样的故事，一个团队说这是个2，另一个团队说这是个6，那就不是很有趣了，当然这样比较两个团队也不是个有效的方法。 现在我们怀着好奇心来了解这种状况，首先判断条件是否足够相似来比较，其次试问估算更高的团队，是否需要咱们能提供的帮助。这样就很好。隐式或显式地结束”更慢”团队的劣势或以某种方式搞砸——这将是非常糟糕的事，但不幸的却是很常见的。 我认为对很多管理者来说，比较两个产品团队是件极其诱人的事。在可能的情况下，抛开故事点的概念，甚至抛开评估点的概念，我认为也是足够不可抗拒的。我们回到如何用更少的估算来开展工作问题上，这里还有其他的文章也讲到这方面内容的。 跟踪 对于很多管理者，估算的存在意味着”实际”的存在，意味着你应该拿估算与实际比较，确保估算与实际相匹配。当估算与实际不匹配时，就意味着人们应该要学习如何更好的估算。 对我来说，真正的敏捷里最重要的是选择接下来要做的事，并且立即开展去做。最关键的问题是找出最有价值的事做，并且快速实施。快速开展去做，归结为去做小部分价值高的和快速迭代。如果不这样做，故事成本估算帮助不到什么。 因此，如果估算的存在让管理者把注意力从价值中移开，取而代之的是改善估算，把精力从快速交付真正有价值的东西转移。 这让我觉得估算，不管是点还是时间，都是浪费！ 压力 有关估算/实际涉及的是老板们需要”更多”的自然压力。尽管很多团队已经完成了，这是不够的。更多，更多，更多。 交付有价值的东西，最好的方式不是更多、更多、更多，而是频繁的做有价值的东西。如果我们把故事分解到”足够小”替代估算故事，从而达到一直持续平稳地交付有价值的东西。 聚焦在更多的增值。让团队在越来越大的压力下做更多的需求，不可避免地会产生一个坏结果：团队试图更快速地去做，而忽略代码质量和测试。他们瞬间开始承载越来越多的缺陷，因为持续返工去修复缺陷，甚至由于代码质量迅速下滑而放慢速度。事情变得越来越糟糕，压力持续增长，这将演变成一场灾难的节奏。 由于估算至少被卷入过度压力的投入中，我宁愿避免。 我更深入点：我宁愿完全避免迭代或冲刺计划。在接下来几周，我们不会为去填补预算而工作，而会因为接下来有几项最重要的事情清单而做。 预测完成 一种常见的做法是做个基本特性列表，先想一会，然后决定定义我们产品的下一次发布。当然，接下来的问题是”这些什么时候能全部完成？” 没有人知道这个问题的答案。我们可以做很多工作来改善我们不知道的事，在某些领域和某些时候，这当中的一些事也是值得做的，譬如当一个大的合同等待投标的时候。但是当我们正忙于开发内部或外部客户的解决方案时，尽可能地频繁提供少量有价值的东西，而不是等到通常会无限期拖延的全功能一起发布。 选择临近下一次发布给客户的日期，尽可能地挑选好东西到发布中，这样更好。估算故事点或时间阻碍了交付。在我看来，如果可能的话，这最好要避免。 分解（拆分） 那么问题来了，如果你不喜欢故事估算，那你喜欢什么呢？好吧，我喜欢故事分解，它是将大的故事点分解成更小的故事点集合，每个小故事点尽可能高的价值，然而只需要很少的时间就可以完成，理想情况下，少于一天，也许只是几个小时。 现在，我不在乎与你争论分解（拆分）时是否必须进行某种估算。如果你或者你团队的估算只是在脑海里，没有告诉任何人，那么，不论是故事点或时间的估算问题，就不太可能提出来。当然，了解故事点”可能足够小”和”可能不够小”之间的差异并不等同于知道”三天”和”一天”的差别。 另外，这有个技巧。我在 Getting Small Stories 和Slicing, Estimating, Trimming有提到。我也是从Neil Killick学的：分解故事直到它只需要一个验收测试。一个好的故事点只需要很少的实践。 当然，还有关于估算主题的其他文章，点击链接会有超乎你想了解的。 预测将来 但是…难道我们不应该合理的知道一个产品发布需要多长时间和估算是否必要吗？然而也许这不是故事估算。你应该不会把你的需求归结到故事层面，若这么干，貌似是很大程度的浪费。 当然，如果你必须要这么做，那就这么做。无论我做什么或者我的关于你该做什么的理论，只是理念。最终你需要做的是在自己所处的环境下尽一切可能的成功。只是我觉得可以有些更好的东西。 第一，想想下一次发布的一个或多个重要功能。讲讲这些功能可以解决什么问题和什么样的软件可以帮助解决这些问题。谈谈可以解决一些问题的最简单功能。我们不必要解决所有的问题：通常我们提供一些解决方案足以推动事情的发展。 第二，想一个到那时你觉得可以构建出一些好的功能点的时间节点。设置最后的期限并开始着手工作。 第三，再分解重要的功能故事点并实现它。你应该能够在一天或更容易地实现。只做下一步最重要的：别试图老是先实现边边角角的功能。你应该尝试这样的思维框架”如果做了这个小东西，客户Jack就会在实际中使用它”。然后，就做这个小东西并且让客户Jack试用它。我们想尽可能快的持续传递价值。 我们想把正在做的东西的价值明显化，让产品经理或者其他老板等不及想看到产品。这样…我们就在有或没有故事估算的情况下做了正确的事。
2020/4/23
articleCard.readMore如何打造优秀的远程敏捷团队（9步）
最近怎么样？ 可怕。我的团队很担心，我们感到与世隔绝，并且我很难将我们重新团结在一起。 听起来很有挑战性。 它是。真的是这样。我只是不了解我所了解的其他团队之间的合作情况如何。 嗯，团队其他成员的感觉如何？ 我认为我们每个人都感到同样，沮丧和孤独。 不需要这样，让我们扭转一下…… 通过经验学习Scrum的核心。 作为一名活跃的敏捷Scrum顾问和专业Scrum培训师，我一直在帮助众多敏捷团队。毫不奇怪，我所支持的所有团队都在尝试不同的方法来使远程工作正常工作！ 我发现有些模式在表现非常出色的团队中很常见 1.创建一个团队WOW (Way of Working) 对于在线工作，团队”工作方式”方法一直是出色的在线Scrum团队执行的首要行动。 Team WOW是团队为自己创建的协议，概述了Covid19发生时我们作为团队将如何合作。一个优秀的团队WOW将回答以下一些问题； 我们将如何合作？ 我们会喜欢Skype、zoom等实时通讯而不是电子邮件吗？ 如果我们决定采用实时方法（好！），那么我们会鼓励打开摄像头还是关闭摄像头吗？ 我们将使用哪些工具来共享我们的工作？ 我们将使用哪些工具来可视化进度？ 我们的主要工作时间是什么？ 我们将如何互相帮助？ 我们将如何保持联系？ 随着事情的变化和我们了解更多，我们将如何更新WOW？ 2.高带宽的沟通 对于日常协作，优秀的团队更喜欢在线的实时通信，而不是电子邮件。协作良好的团队通常会优先考虑 通过视频会议和可视化的网络电话，而不是拨打电话 通过拨打电话，而不是聊天工具 通过聊天工具，而不是电子邮件 通过发送电子邮件，而不是烟雾信号 与我合作的一些团队有主要的视频会议时间，因此他们的摄像头会打开一段时间，以在一天中的一段时间内营造一种联系感。就像和您的团队一起坐了一段时间。其他人仅将视频会议用于安排的会议，这对他们来说就足够了。让您的团队来决定什么工作方式的会议（请参见上文）是有用的，并对其使用进行纪律。 3.实时协作工具 这些工具是团队在分布式时间内保持生产力的重要组成部分。缺乏透明度是我们所有人都应该担心并不断改进的问题。如果我们不知道发生了什么，我们将如何相互支持和帮助？我们如何消除阻碍保持创新和不断创造价值的障碍呢？ Trello，Microsoft Azure，Asana，Mural，Miro等协作工具为团队提供了跟踪进度，共同计划，共同回顾和不断保持我们的工作和思想对团队透明的方式，以便我们可以检查，适应克服摩擦并不断创造价值。尝试一些，采用一些。 4.迭代，使用追溯驱动的变更方法 永远不要低估团队不断学习的力量。在充满挑战的时代，我们永远无法确定会遇到什么。如果您是使用Scrum的敏捷团队，那么您已经在使用回顾来了解什么对团队有效，而哪些无效。您已经在适应新情况；您一直在评估自己的工具，并且对新的交付方式保持开放态度。回顾可以帮助我们检查对团队有用的东西，而不是无效的东西–这不仅仅是物理上的东西。良好的回顾有助于消除情绪上的摩擦，帮助我们检查团队的心理和社会健康；对于细心的团队而言，回顾可以帮助我们在出现灾难之前就对问题进行预警。回顾会通过改进问题来帮助我们变得更好。 5.安排调整后的核心工作时间 最好的团队认为，由于我们的孩子，宠物和家属现在与我们在一起，因此标准的9点到5点工作模式可能不适用。在我们的孩子休息或吃午饭，或者狗需要走路，或者年迈的父母需要检查的时候安排会议可能是不现实的。适应新常态的团队会更改其工作模式和核心工作时间，以消除日常挑战。Scrum提供了一种最小的事件模式，事实证明该事件可以在更改时起作用。最好的Scrum团队已经适应了这些事件，以应对团队特定的调度挑战。 6.测试灾难恢复 您的团队已经在使用回顾来适应吗？如果是这样，那么您可能已经在寻找保持连接的备份方式，并在发生意外情况时可视化工作。如果您的高速宽带停止工作，您的备选方案是什么？对备份技术和方法进行同步测试可帮助团队向前看，切换到备份并保持工作。最近，在进行专业Scrum Master培训时，我的互联网完蛋了。某个地方的某人认为这是切入某些电缆的绝佳时机。多么不方便。 幸运的是，我已经花了几天时间在我的移动互联网提供商之外进行培训，并且已经进行了测试备份。几分钟后，我又开始工作了，培训继续进行。您所依赖的关键技术是什么？这些技术失败的可能性有多大？您打算坚持不懈地进行哪些工作？ 7.共同缓解技术摩擦 在家工作时，面对所有挑战，学习新技术似乎令人生畏。没必要。一旦您的团队选择了一些好的工具，一种快速学习它们的好方法就是安排学习课程，我们在彼此之间互相教如何在安全的支持环境中最好地使用这些工具。 当我过渡到画画时（上课不用ppt）-我有些沮丧，我只是想不出如何让壁画去表现我想要的样子。幸运的是，Ralph Joachim邀请我参加他的一项在线练习活动，我可以从他的经验以及其他15个专业Scrum培训师的经验中学到东西。拉尔夫（Ralph）创造了一个安全的空间来回答问题，无论是简单还是复杂。结果全面而快速的学习。当我的互联网失败并且我使用壁画通过移动设备进行了培训时，我没有错过任何拍子，为此我有拉尔夫表示感谢。 此外，学习的团队可以快速适应新工具，有意识地互相帮助，并使用协作安排的课程来一起实验，学习和回答问题。他们不希望它，他们计划并且有意识地互相支持。作为对此的扩展，如果您发现您的同事很挣扎，请提供支持并为他们提供支持。刻意帮助您的团队克服和掌握我们所有人面临的技术挑战，不要以为每个人都知道如何很好地使用所有工具。 8.接受学习，解决问题 动荡的时代意味着我们不会每次都正确。出现问题时，很容易对自己和同事感到沮丧。我们需要对我们的团队耐心等待。学会记住，鉴于他们的技能，能力和可用资源，每个人都在尽自己最大的努力来应对面临的挑战。 敏捷不是要怪罪责，而是要把湍流当作生活的一部分并刻意解决问题而不怪罪。 9.安排非工作事件 我认识的一个管理团队在星期四晚上向他们的团队发送信息，以进行星期五的hangout活动，您能猜到在那里工作的人的士气吗？其他团队在工作日结束时会进行30分钟的视频群聊，以讨论非工作玩笑和咯咯笑声。一些团队已经决定每周一次就足够了。尝试对您的团队有用的方法。 保持在线 请记住，Covid-19意味着我们必须在身体上相距遥远，但我们不必在社会上相距遥远。使用以上方法可以使您与团队更紧密联系，并成功克服当今的挑战。保持。连接的。 我们必须使自己摆脱海洋将永远安息的希望。我们必须学会在狂风中航行。 〜亚里斯多德-奥纳西斯
2020/4/22
articleCard.readMore谷歌OKR指导手册 (译)
译者：乔梁 来源：《持续交付2.0》公众号 这是一本关于 OKR 迷你小册子，名为《google OKR playbook》，由 www.whatMatters.com 网站发布。 该网站由John Doerr 团队经营， 而John Doerr 正是 1999年将 OKR 引入 谷歌的那个人。 本文仅供大家学习参考，虽然文章较长，但值得一读，欢迎收藏。 文章的末尾有一些 8 道自我测试题，用来验证你的OKR是否在正确的实施。 如果你正实施OKR，可以用它们来验证一下吧～ 在实现OKRs方面 没有人比谷歌更有经验 随着公司规模的扩大，它定期发布 OKR 指南和模板。以下摘录主要来自内部资源，并经谷歌许可转载。 （注：这是谷歌对 OKRs 的做法。你的方法可能不同，也应该不同。） 在谷歌，我们喜欢大张旗鼓。我们使用一个称为目标和关键结果（OKRs）的过程来帮助我们沟通、衡量和实现这些崇高的目标。 我们的行动决定了谷歌的未来。正如我们在互联网搜索、Chrome 和 Android 中多次看到的那样，一个由少量员工组成的团队，朝着一个雄心勃勃的共同目标努力，就可以在不到两年的时间里改变整个成熟的行业。 因此，作为谷歌的员工和经理，我们必须有意识地、谨慎地、明智地选择如何分配我们个人与团队成员的时间和精力。OKR 是这种谨慎选择的体现，也是我们协调个人行动，以实现伟大集体目标的手段。 我们使用 OKR 来规划要生产的产品，跟踪它们的进度与计划，并协调人与团队之间的优先级和里程碑。 我们也用 OKRs 帮助大家专注于最重要的目标，并帮助他们避免被紧急但不太重要的目标分散注意力。 OKR是有野心的，它不是逐步增量式的，我们并没有希望一次性就完成所有这些野心。（如果我们真的这样做，那么，我们就不会具有足够的进取性）。 我们用色阶来衡量我们做得有多好： 0.0 – 0.3 是红色● 0.4 – 0.6 是黄色● 0.7 – 1.0 是绿色● 正确的OKR制定方法规则 没有认真实施和管理的OKR，是一种时间上的浪费，是管理上的假大空。与之相反，如果实施得好，OKR将是一种很好的动机激励工具，它能让团队明白什么是真正重要的，哪些地方需要优化，在日常工作中应当如何去进行利弊权衡。 要写出好的OKR可不是一件容易的事，但也不是不可能。请遵循如下这些简单的OKR制定规则： 规则1：O 要回答的是 “What” 的问题，它应当： 表达清楚目的和意图；
2020/4/22
articleCard.readMore敏捷不是反管理，而是更加激进！
译者：Nikijv 审校：Bob Jiang 英文原文 一个Twitter的帖子问”敏捷”是否反管理，以及”敏捷”为什么经常看起来很像反管理。简单写一下，本文中我个人的观点是敏捷软件开发如敏捷宣言所设想的那样，并不是反管理。这比反管理更激进：这是一种完全不同的管理方法。 敏捷软件开发仍然比当今的认知更激进，相当的不幸，包括大部分品牌和方法，在我这个有点老的男人对云观点大喊大叫的时候，也被大多数较小的”敏捷”供应商所采用。 敏捷软件开发正如我们所定义的那样，对于业务与开发间的日常协作较为频繁，以维持增量的可工作软件。这样团队称为自组织团队，尤其要说明的是：最好的架构、需求、设计来自这些自组织团队。 原则上很清楚，软件、架构、设计等一切工作都源自于团队，从团队中涌现。 例如，需求不来自于一些业务单元，而是通过中央委员会进行传递，然后传递到一些传统部门或项目部门直到它落在一些程序员的办公桌上。 这不是”反”管理。这根本不涉及解决类似于预算工作、人员补偿、评估性能或者其他”管理”关心的主题。 当然，敏捷软件开发提出了一个新的、不同于软件产品制作的管理。尤其通过基于工作软件的可持续生产使用的自组织、增量、速度技术，是解决软件开发应该被管理的新方式。 敏捷是反管理的么？我不这么认为，敏捷明确反泰勒式的管理，而支持推动管理。 同样，像所有好人一样，我们更乐于好的富有成效的管理，强烈反对贫瘠、无效、有害的管理。 但是我想建议这个底线是： 如果一个组织试图通过任何传统的方式控制团队的选择，该做什么以及如何做的选择来管理敏捷软件开发，这样很可能他们做错了。 如果你是敏捷的支持者，你试图与传统管理达成某种中间状态或和解，有可能你也是没有真正理解敏捷软件开发的根本意图。 一、scrum在发光 考虑到Scrum的构想，最流行的敏捷方法如果不是最有效的，那什么是？ Scrum称为自组织的团队，包括产品负责人，被授权于全部权利和责任，负责大型组织团队的投资回报率。Scrum团队中Scrum开发者的开发团队，必须包含交付产品增量的”全部必要技能”，一个被集成、测试过的、可工作软件包括团队迄今为止产生的所有价值元素。 Scrum承认Scrum团队是嵌入式的，以某种方式，在一个组织中，组织提供了资金（投资），干系人关心Scrum团队做了什么。敏捷团队通过每个冲刺向干系人展示他们已完成的工作，邀请并听取干系人的意见。Scrum团队与全权负责的产品负责人决定下一个冲刺做什么以及怎么做。 冲刺审查是Scrum团队及其嵌入组织之间的完整接口。 关于Scrum仍然有些问题没有解答，同样这些问题在上面Twitter的帖子中也涉及到了。Scrum不会告诉你如何预算，如何决定补偿，如何评估性能等等。 在Scrum课程中，人们经常询问各种管理职能。有个经典实践可以回应，课程上小组在便利贴上写下他们能想到的所有管理职能。他们可以把这些便利贴放到下面4个位置：开发团队，产品负责人，Scrum教练以及其他。 将会有两件事发生。首先，许多传统管理职能转移到一个或多个Scrum团队元素。由团队分配任务，由产品负责人决定要构建什么，由Scrum教练支撑和引导等等。有趣的一点是，总有些管理职能被贴到其他堆中。Scrum甚至不会建议如何做这些：这已经超出了Scrum的范围。 然而，很明显，Scrum打算不管这些超出范围的管理职能是什么，它们与团队的首要接口，可能只通过冲刺审查。尤其是除了产品负责人，没有人可以要求团队做任何事情，Scrum对”经理”在Scrum团队运行时可以做什么做了非常具体的限制。 二、敏捷软件开发是反管理么 敏捷软件开发需要一种新的管理方式，在团队规模上，团队内部拥有对产品的所有权利和责任，而且最主要的接口是检查实际演变的产品。 不一定是”反管理”，但一定与某些类型的管理背道而驰，尤其是源自于泰勒主义更具有侵入性的形式——福特主义，将工作视为机器，工人几乎没有权利或仲裁。尽管敏捷软件开发肯定要求从团队内部而不是外部应用这些概念，但与戴明和统计过程控制等概念的对立程度要小得多。 但我觉得主要的概念已经相当清楚：敏捷软件开发是一种完全不同的管理方法，尽可能的把权利和责任下放给团队。这种管理方法对于如何走得更远没有设置上限，但它设定了一个相当严格的下线，这个下线是嵌入在团队内部的产品做什么以及如何做。 三、这些想法的限制是什么 这很难说。我们通过敏捷团队的成长能力去决定谁在团队谁不在团队，这对薪酬和评估有很大影响。我们开始听到团队中的谁直接与客户合作，客户有时基于固定价格安排，或者更常见的基于运行速率为产品提供资金。 今天，更多的限制是被组织强加的——试图做”敏捷”，这些限制中有很多是明显错误的。有时组织没有从战略上很好地理解最好的管理是如何的。我通常认为,个人管理结构应在敏捷之前就位：不同的团队成员”属于”一个或另一个经理,而该经理则继续尝试对团队成员的行为进行控制。 坦白讲，自组织团队被授权，而这导致冲突、混乱以及很多时候应该做敏捷组织主要来源走向黑暗敏捷。这个观点是正确的。 底线，敏捷软件开发提倡不同的管理方式，很可能与一些过时的管理观念不相容，不幸的是，这些观念在今天仍然相当普遍。 反对的？不。完全不同？是的。 原文链接
2020/4/21
articleCard.readMore知行合一的敏捷实践 来自道富银行 杨贵的分享实录
知行合一的敏捷实践 内容来源：敏捷+社区线上直播003期，《知行合一的敏捷实践》分享实录 分享者：道富银行敏捷教练杨贵 关注本公众号回复“知行合一”即可获取本次分享的视频回放、下载PPT。 一、原动力-你在为谁工作 在敏捷实施过程中，有几个问题很关键，包括组织的问题、人的问题、执行力的问题。其中组织的问题不在我们个体控制范围之内，今天主要聊聊人和执行力的问题。 点击阅读原文 查看回放 总结 总结来说，知行合一的敏捷实践要求做到： 价值观的认同，团队成员要有一致的价值观。 工作过程有章可循，定义好活动规则和检查规则。 团队成员积极参与。制定各项规则的owner。 反馈闭环，以数据驱动反馈闭环。 技控，用机器和工具来解决问题。
2020/4/20
articleCard.readMore我在哈啰的敏捷之旅 | 敏捷家分享005
内容来源：敏捷+社区线上直播005期，《我在哈啰的敏捷之旅》分享实录 分享者：哈啰出行陈文博 关注本公众号回复“哈啰”即可获取本次分享的视频回放、下载PPT 非常开心在空中和大家相聚，希望在接近一个小时的时间我们都能有所收获。首先感谢Bob老师和网易杭研的李岩同学，是因为他们的支持，我才能够在这里和大家分享。在开始之前，先简单自我介绍一下，我是陈文博，供职于哈啰出行PMO部门，一名成长中的敏捷教练，今天有很多敏捷社群的小伙伴来支持，谢谢大家！ 【正式分享之前，先上一个彩蛋】 查看原文 言归正传，今天的分享将分为两部分： 第一部分是我在哈啰做的一些敏捷实践，包括目前我是怎么操作Scrum的，如何利用透明拉通团队共识，如何利用内驱力模型来激励团队，以及我在兼顾多个Scrum团队时如何培养内部的Scrum Master。 第二部分将给大家分享我在内部敏捷社区的一些做法，包括我是怎么发起内部敏捷社区Thor，以及社区是怎么运营的。 一、我的敏捷实践 首先给大家分享的是敏捷宣言的第一句话，”我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。” 分享这句话的原因是，我觉得敏捷实践是没有最佳实践这么一个说法，永远都是在不断地迭代，不断地找到更适合当前组织和团队上下文的一种做法，所以我在这里给大家分享的，也是基于我自己团队的上下文找到的目前最好的方法，后续还会继续迭代，以便做得更好。 查看原文获取更多材料
2020/4/19
articleCard.readMore自由职业者访谈录：对话图书出版达人/职业规划师/程序员安晓辉
采访回放 - B站 | Youtube Bob：大家好，很高兴本期访谈邀请到了安晓辉。晓辉，先跟大家做个简单的自我介绍。 安晓辉：大家好，我是安晓辉，我用三个标签介绍一下自己： 第1个标签：程序员。我从2005年-2017年，做了12年软件开发，从2009年开始，也做了一些研发管理的工作。在当程序员的这段时间里，出版了两本软件开发相关的图书，《Qt Quick核心编程》和 《Qt on Android 核心编程 》。 第2个标签：职业规划师。我从2015年开始帮人做职业规划，形式包括分答、知乎、在线微咨询等。到现在为止，这种1对1的咨询进行了500多个小时，帮助过200多个人。 第3个标签，图书作者。在介绍程序员这个标签时提到了两本书，实际上我出版的不只是技术图书，还有程序员成长相关的，比如《程序员的成长课》、《大话程序员》，现在最新的一本书是讲怎么做副业，《副业赚钱之道》。 我现在是自由职业的状态，工作主要是写书、课程还有咨询。 Bob：你能给大家介绍一下写书的经验吗？ 安晓辉：大概是在2013年左右，我开始写技术博客，2013-2015年，正是移动开发非常火爆的时候，我写了几篇关于Qt在安卓上的应用的文章，在CSDN技术博客上发表。出版社找到我说要不要做一个这样的选题写一本书，因为我本身比较爱写东西，所以就答应了。 写书还是很有挑战的，特别是在时间管理上。因为当时我还在上班，纯粹是利用业务时间来写书，有时候晚上12点多调完代码再开始写，早上5点多又起来继续写，周末的时间也在写。从2013年底到2014年10月，投入了将近10个月的时间。这是我第一本书的出版经历。 虽然投入了很多时间和精力，但是写书的过程还是让我受益良多，当然这个收益不是指经济收益。技术图书的销量和你所写的技术有关，我当时写的Qt这种技术，是相对比较小众的，卖个几千册算不错了，所以经济收益这一块其实并不算大。 我所说的收益更多的是个人影响力的提升，写了两本书之后，我在Qt这个小圈子里就比较有名了，写书能提升个人影响力，能为个人品牌提供一个比较好的背书。 另外，写书能帮助个人对自有知识进行体系化、结构化的梳理和总结。写书是一个比较长期的事情，需要你有足够多的知识储备，要对所写的领域有全面、深入的理解，也会在无形中强迫你不断进行输入，再进行结构化地输出。 Bob：据悉你在知乎live上有一个很火的课程《业余时间赚钱的六个策略》，说说当时是怎么想到要在知乎live上做这样一个话题？关于在知乎上做这种直播分享，有一些什么技巧可以跟大家分享的呢？ 安晓辉：还是延续刚刚说到的，出版了两本技术图书之后，我在这个小圈子里有了一些影响力，有一个平台找到我说想做这种直播的课程，后来我们选择在知乎上做直播。 大概在2017年的元月初，做了第1次知乎live直播，主要是面向程序员，反响还挺不错的。有一天我在开发系列课程的时候想，大家可能对赚钱比较关心，要不要设计一个课程讲怎么赚钱呢？于是我就去搜各种各样的赚钱的策略，花了大半天时间把方向定下来，然后结合自己做过的事情、搜集到的各种信息把课程做出来。 这个课程得到了知乎官方的推荐，加到了信息流中，增加了曝光和传播，我讲的内容也比较有意思，课程很受欢迎，后续有很多人购买，到现在购买人数应该已经超过5万人了。 在知乎live进行直播的经验，我觉得有一点很重要，你如果要做轻量的分享或者讲座类的小课程，选题特别关键。要融入到知乎的生态里，知乎上有很多免费的回答，这些都跟付费的课程是连通的，在知乎上有关注的话，你的回答就容易被别人浏览到，可以在回答中推荐你的课程，别人看到觉得不错就会购买。 我一直在知乎上回答问题、发表文章，在回答和文章中也会去推荐我的课程，保证持续曝光，现在我的知乎号有将近11万的关注。让课程和产品被更多的人看到，转化自然也会更高。 所以，在知乎上做课程，首先要有一个好的选题；第二是宣传材料要设计得比较吸引人；第三是保持持续曝光；第四内容一定要足够干货，这样大家听完后反馈很好，也可以吸引更多的人来购买。 Bob：作为自由职业者需要具备哪些技能？ 安晓辉：我认为应该先对技能做一个分类：专业技能和通用技能。 写作是我的一个技能，通过在公众号、知乎等平台发表文章吸引关注、建立影响力。 课程设计和开发是我的第二个技能，我现在大部分收入是来自课程。 第三个是营销的技能，选择自由职业后，你一个人就成一个团队了，你的东西要让别人知道，就得懂一些营销的心理学，还要策划一些宣传文案。 第四个是演讲的技能，当你要面向企业或客户做产品或提供服务时，需要通过一些渠道来曝光自己，比如参与技术峰会的演讲、线下活动的分享等。通过你的演讲，可以让更多人知道你的状态、水平，从而吸引更多客户。 上面这些可以归于专业技能，专业技能是跟你做的事情相关的，如果你的自由职业是软件开发，那你的技能就是开发；是做课程，技能就是课程开发。 通用技能则包括：时间管理、任务管理、目标管理、沟通和谈判等。在公司时，面向内部沟通相对来说要简单一些，自由职业后直接面向客户，有时候还要去跟客户谈判，比如这个课程做成什么样、收费多少等。 Bob：这么多技能中，能给你带来直接收入的有哪些？ 安晓辉：咨询，1对1咨询，按次收费，这是最直接的。 课程开发、为企业提供内部培训，按天收费，也是直接可以带来收入的。 写作方面，出版图书、商稿（公关稿）都是有稿费的。 Bob：你下一步会做什么事情呢？ 安晓辉：实际上自由职业有一个很重要的问题：有没有一个稳定的模式？就是说你能做多久？这个产品/课程能卖多久？很多人会发现自由职业做着做着就难以继续下去。 我现在在构建我的一个产品矩阵。设计一个和《副业挣钱之道》相关的训练营，这样一来我就有书、有课、有训练营，再加上线下课、咨询，形成一个产品矩阵和循环，然后在这一块继续深耕。 安晓辉：程序员/职业规划师/图书作者
2020/4/17
articleCard.readMore敏捷与OKR -系统思考与组织设计的艺术 | 敏捷家分享004
内容来源：敏捷+社区线上直播004期，《OKR与敏捷》分享实录 分享者：有赞效能改进工作者费解 关注本公众号回复”有赞”即可获取本次分享的视频回放、下载PPT OKR是一个很热门的话题，我所在的公司（有赞）很早以前就开始实行OKR了。2014年老板去硅谷进行调研，带回来一种新的管理方式，一直执行到现在。本次分享也是我在OKR实践方面的一些经历和感受。 OKR与项目管理、敏捷，都是一种提升公司或组织效能的手段，OKR与敏捷之间也有着千丝万缕的联系，它俩是相通的，都有很多不确定性，不是你做了就一定能成功，还需要达成很多平衡。 管理是一门艺术，系统思考和组织设计，是两种底层能力，在敏捷实践过程中一定会涉及到。要组建一个敏捷团队，一定要有具体的角色，我们在组建团队的时候就开始做组织设计，在大规模敏捷框架里，组织设计也是一项非常重要的工作。 小调查 你在组织中处于什么角色？ 你在组织中处于什么角色？比如项目经理、敏捷教练、ScrumMaster、技术负责人等。你在做决策时，是否客观？很多时候在小范围内做局部优化工作，没办法做到全局理性，为什么呢？我们发现，无论是什么角色，在做自己工作的过程中，视野会被工作范围所局限。 如何突破自身的角色和有限的视野，看到更大的范围和跃迁到更高的维度，就要回到系统思考的话题。 系统思考来源于系统动力学，是一门学科。其中有一个属性，系统有一种层层嵌套的现象，所看到的是一层，如果想要看到更大更高的那一层，就要跳出所在的范围，到更高维度的世界去。实践敏捷也是如此，需要系统思考和更高维度的视野。 我的敏捷世界观 见山就是山 | 见山不是山 | 见山还是山 我的敏捷世界观： 见山就是山。最开始接触敏捷的时候，从课程中学到很多关于敏捷的方法、工具等，比如：三三五五。那时认为敏捷就是这个样子的，要实施敏捷的话，以它提供的框架，按部就班地来执行就可以了。这个阶段学到的是敏捷的形，没有参透敏捷的本质。 见山不是山。后来经历了很多项目管理、组织优化、效能改进的工作，不经意间会根据需求和场景，将学到的敏捷知识和方法加以变通，灵活运用到实际的工作中。比如：基于整个组织的现状，运用同理心，感受需要被引导和改进的部分，然后慢慢结合敏捷去实践。随着时间的推移，我们在更多领域中加入了敏捷的元素，也做了一些创新。这个阶段是领会到敏捷的本质，逐渐融会贯通的过程。 见山还是山。经过反思沉淀后我们发现，敏捷给出的方法论适用于很多工作场景，能解决很多问题，是前人经过无数实践总结出的方法。我们也会慢慢去反思：为什么要做敏捷？敏捷的本质是什么？ 我认为敏捷的本质有三个： 优先级。我们的优先级是否明确。在一个团队或大的组织中，有没有做事的方法？优先级是什么？人在同一个时间段只能做一件事，先做哪件后做哪件？ 高质量的交付。我们做事的目的一定是为了交付，为了产生价值，高质量的交付是敏捷的一种结果。 灵活变化。我们的组织或团队是否能够灵活应对外界的变化。如果是就是敏捷的，也不用刻意强调三三五五，僵化的敏捷不是敏捷。 一次灵魂拷问 你存在于组织中的价值是什么？ 前面问的是你在组织中的角色是什么。现在我们思考一下：你在组织中的价值是什么？是管理项目，还是作为一个敏捷教练带领敏捷团队？我们的出路在哪里？关注在哪个层面？ 敏捷之上的世界 大千世界 | 道法术器 | 价值在外 根据系统思考的原则，需要看到更高的维度。因此除了敏捷之外，还要看到敏捷之上的世界，看清问题的本质。 佛曰：三千世界。世界之外还有世界。在实行敏捷的同时还应该有更高维度的思考和实践。 道法术器。道法是指我们学敏捷不应只是学习它的方法，还应该理解其本质；器是工具，工具是管理的辅助手段，在工具的制定方面，一定是工具适应组织，而不是组织来适应工具。在敏捷实行过程中，即便工具设置得再好，如果实际操作起来完全不匹配组织的现状，使用起来也会很别扭。术包括敏捷方法提供的框架和工具，比如前面提到的三三五五之类的。在这里值得注意的是：要站在道和法的层面，从更高的角度来审视，是否需要用到所有的这些工具，避免生搬硬套，使敏捷变得僵化。 价值在外。不要以为敏捷团队的敏捷就是端到端的了，在敏捷团队之上还有更高维度的团队，比如：部门、业务线、事业部、甚至公司。我们要从全局看整体的目标是什么、以及是否达成。敏捷团队产生的价值是什么，包括对公司的价值和商业价值。 “价值在外”这个词是管理大师彼得德鲁克提出的，即：我们所做的任何事情都是在组织外部，才会被评价和被认可的。我们所做的动作，是帮助公司完成敏捷转型，还是是为公司创造价值？在做组织设计时，我们也需要面向是否创造外部价值。 查看原文获取更多材料
2020/4/12
articleCard.readMore博客搬家 - 记第四次搬家(hugo建站推送到谷歌云存储)
修订历史 2020.05.19 修订2个错误 - 1. 新域名需要绑定 Google Search; 2. Google Cloud Storage 权限设置。最近新搭建了敏捷家的博客，发现了前面的两个错误。 2020.04.10 创建 写在前面，搬迁记录 记录我的博客这次搬家过程。我的博客之前经历过： wordpress github page Bitcron - 机制很不错（写完的博客自动保存到dropbox并发布，可惜搜索引擎的收录不是很好。） 这次搬迁 2020年4月10日 初步完成 博客的架构 现在写博客一直采用 markdown 语法，所以也是本次可以顺利迁移的一大前提。 最近两年一直用的是 Bitcron ，非常顺滑。每次写完 md 文件，直接保存即可（博客立即更新可见）。不过一直搜索引擎的收录不是很好，如我直接搜索 “Bob Jiang” 我的博客始终排不到第一个。很奇怪…… 索性现在申请了一年免费的 google cloud，就做个搬迁。 搬迁之后的博客存储在 google cloud storage 上，DNS也顺便切换到 Cloudfare 上了。 博客系统使用的是 hugo ，主题用的是 Ezhil。博客整体存放于 github上，每次提交到github会自动出发一次 github action，推送到谷歌存储。 博客的工作流 博客的工作机制如下： 本次编写博客(md文件) 并本次检查 (hugo server) github push 到 github 仓库 每次 push 或者 pull request 会出发 github action github action 进行 hugo 编译 github action 推送博客静态文件到 谷歌存储 博客的配置 (手把手教你配置) 第一步，配置hugo 安装 hugo 可以参考我朋友的博客，免费搭建一个静态博客。搭建完成后，关于主题，这里我采用的 hugo 主题是 Ezhil，可以直接用 github fork一份 hugo 主题。具体操作参考 Ezhil。
2020/4/10
articleCard.readMoreEdmund Hillary Fellowship (EHF) 介绍
EHF webinar 回放 Edmund Hillary Fellowship (EHF) 介绍 EHF是Edmund Hillary Fellowship （EHF）的缩写，即埃德蒙·希拉里伙伴计划，专注于影响力创新和企业家精神、独特的新西兰移民计划。EHF将世界级的企业家和投资者带到新西兰，一起为这个世界产生积极的变革。 走在伟大的脚步 埃德蒙·希拉里伙伴计划（EHF）的产生是为了纪念埃德蒙·希拉里（Edmund Hillary）爵士的精神和记忆，埃德蒙·希拉里（Edmund Hillary）爵士是第一位登顶珠穆朗玛峰的人，与滕青·诺盖（Tenzing Norgay）一起。埃德爵士（Sir Ed）是一个毕生奉献的人道主义者，他在著名的攀登之后花费了数十年，以改善喜马拉雅山的夏尔巴人社区的生活，修建学校、医院和飞行培训中心。EHF由希拉里国际领导学院全权拥有，将我们的核心价值观与同名的埃德蒙·希拉里爵士保持一致。 伙伴计划（The Fellowship） EHF一年有两次机会（Cohort）申请，每次申请通过后可以参加当年的 New Frontiers Summits，及 Cohort Retreat。并且会有区域性聚会，如惠灵顿的每月EHF Fellow聚餐。还有线上的连接与非正式的协作，以及EHF团队的积极支持（如签证、落地等）。 好处（Benefits） EHF Fellow可以申请 Global Impact Visa （全球影响力签证），EHF是创新者非常棒的开放社区。 为什么要去新西兰（Why New Zealand） 新西兰是个非常适合生活的地方 这里有强大的政治权利和公民自由；也是全球腐败程度最低的国际；还是世界上非常和平的国家 令人称赞的文化 新西兰的土著文化很赞；世界上第一个妇女拥有投票权的国家；并且这里是多元化的国家。 非常适合初创企业 全球最容易开展业务的国家；紧密联系东西方；拥有良好教育的劳动力 新西兰的企业 Weta Digital (威达数码) 威达数码由彼得-杰克逊、理查德-泰勒和杰米-塞尔柯克创立，为包括《指环王》和《阿凡达》在内的电影制作视觉效果。威达数码是一家从事视觉特效制作的所有领域的公司，包括前传、动画、表演捕捉、模拟、合成、建模、渲染和研究。 网站：https://www.wetafx.co.nz/ Xero Xero是一款适用于小型企业的在线会计软件。使用Xero来管理发票、银行对账、记账等。 网站：https://www.xero.com 新西兰国土面积较小，因此在全国范围内很容易快速地开展工作→Xero在新西兰与新西兰的银行、政府税务和统计机构建立了联系，比在其他地方做得更快，因此它可以利用这一点向其他国家展示它的能力。 LanzaTech兰莎科技 LanzaTech将废碳视为机会而不是责任，从而彻底改变了世界对废碳的思考方式→碳捕集 与维珍大西洋公司合作 网站：https://www.lanzatech.com/ Rocket Lab火箭实验室 火箭实验室正在重新定义我们如何进入太空，提供一系列完整的火箭系统和技术，包括天气监测、海洋数据收集、作物优化和自然灾害管理。 为数不多的从事民用空间工作的公司之一 在马希亚半岛 网站：https://www.rocketlabusa.com/ 申请EHF 我们的选择标准着重于符合以下条件的企业家、团队或投资者： 有大胆的眼光应对社会中的系统性挑战，并在新西兰和世界范围内产生积极影响。 展示实现愿景的动力和能力。 可以与新西兰建立有价值的长期联系，并利用新西兰的独特优势。 可以为EHF社区和更广泛的新西兰创业生态系统做出积极的贡献。 展现出渴望并有足够的潜力继续进行10-20年的贡献。 体现EHF价值观，将成为新西兰和EHF的友好大使。 申请EHF
2020/4/6
articleCard.readMoreTubebuddy - 必备的Youtube营销工具 | Youtube推广工具 | Youtube利器
youtube发布视频有一个必备工具，tubebuddy。本文详细介绍了如何使用tubebuddy帮助你进行选题，以及youtube视频的优化，youtube视频的营销以及推广。
2020/4/5
articleCard.readMore知行合一的敏捷实践 | 敏捷家分享003
内容来源：敏捷+社区线上直播003期，《知行合一的敏捷实践 》分享实录 分享者：道富银行敏捷教练杨贵 关注本公众号回复“知行合一”即可获取本次分享的视频回放、下载PPT。 《知-敏捷思维模式和价值观》 一、原动力-你在为谁工作 在敏捷实施过程中，有几个问题很关键，包括组织的问题、人的问题、执行力的问题。其中组织的问题不在我们个体控制范围之内，今天主要聊聊人和执行力的问题。 人都是有惰性的，也正是因为人的惰性，才有各种各样的发明，比如汽车、飞机。敏捷也是一样，有人说敏捷是一批懒人在做的事情。确实，实行敏捷开发之前，大家都”不懒”，每天忙着写bug修bug、应对线上的各种各样的问题。 而实行敏捷之后，人就变”懒”了。可以实现一键发布、一键部署，简化了开发操作；引入自动化，不管是回归测试、压力测试都可以用自动化替代；通过交付更高的内建质量，促使软件开发效率和质量得到提升，不用再面对这么多线上的问题；实行自组织团队管理，团队内有完善的规则，大家按照规则办事，不用为了职责范围争吵，不需要任务分配，经理也懒得去管团队了。 查看原文获取更多材料
2020/4/5
articleCard.readMoreBob Jiang的系列文章
Bob Jiang整理的系列文章
2020/4/1
articleCard.readMoreOKR系列
Bob Jiang整理的系列文章 - OKR系列
2020/4/1
articleCard.readMoreScrum Master 系列文章
Bob Jiang整理的系列文章 - Scrum Master系列
2020/4/1
articleCard.readMore自由职业系列
Bob Jiang整理的系列文章 - 自由职业系列
2020/4/1
articleCard.readMore规模化敏捷系列文章
Bob Jiang整理的系列文章 - 规模化敏捷系列
2020/4/1
articleCard.readMoreScrum落地关键实践 | 敏捷家分享002
为什么你的Scrum总是难以落地？而大多数都是”形似而实非”的”敏捷Cosplay”。我们都知道，Scrum流程是简单的，那么落地的难点在哪里呢？其实是人，人是最难搞定的。所以，如何搞定形形色色的人呢？或许，你少了很多敏捷实践，帮你打通各个角色间的竖井，真正的实现价值的流动。 （本文作者-来自网易的李岩老师的直播分享《Scrum落地关键实践》视频回放已上线，关注本公众号，回复”网易01”即可获取视频观看地址。） 一、为什么你觉得Scrum难以落地？ ========================================== 每天都在讲Scrum，你可以徒手画出Scrum的框架图吗？那个经典的”3355”，还记得吗？不妨试试看。 思考： Scrum流程本身有问题吗？ 若流程没问题，那么到底哪里出了问题，没什么难以落地？ 还记得《敏捷宣言》第一条吗？ 所以是个体和互动（人）出了问题！也就是人出了问题！ 很多人可能都看过甚至可以对《敏捷宣言》倒背如流。但是，你看过2001年在美国犹他州雪鸟山那次会议上，Andy Hunt 当时记录的《敏捷宣言》手稿吗？ 查看原文获取更多材料
2020/3/29
articleCard.readMore花时间投资自己
花时间投资自己 Nivi: 如果您必须从事“普通的工作”，则要承担责任以建立您的专业知识（special knowledge） 我们遇到一个常见问题：“我如何找到时间开始对自己进行投资？我有工作。” 您必须花时间开始. 只有开始了（行动了）才知道下一步做什么。 “您将需要花费时间才能开始。要么是学习，要么是储蓄。最好是在一个尚不知道如何培训人员并且学徒制是唯一模式的企业中。” Naval：尝试学习人们尚未完全知道如何教书的东西。如果您正在一个新的且迅速扩展的领域中工作，那可能会发生。这在环境很重要的领域也很常见，在这些领域中，细节很重要，并且总是在变化。投资是这些领域之一；企业家精神也是如此。 对于从硅谷开始的年轻人来说，创始人的参谋长是最令人垂涎的工作之一。最聪明的孩子会跟随企业家，并做他或她需要他们做的一切。 在很多情况下，这个人是完全不合格的。拥有多个研究生学位的人可能正在洗洗CEO的衣服，因为这是目前最重要的事情。 同时，该人参加最重要的会议。他们对所有的压力和戏剧，筹款平台和创新一无所知，这只能归因于房间。 刚从大学毕业的沃伦·巴菲特（Warren Buffett）希望为本杰明·格雷厄姆（Benjamin Graham）工作，以学习成为一名价值投资者。巴菲特提出免费工作，而格雷厄姆回答说：“你被高估了。” 这意味着您必须做出牺牲才能接受学徒训练。 用最陡峭的学习曲线找到工作的一部分 如果由于需要赚钱而无法在学徒模式中学习，请尝试根据自己的工作进行创新。承担新的挑战和责任。找到学习曲线最陡峭的部分。 您想避免重复的工作量，这只是等待时间，直到您的工作自动完成。 如果您是咖啡店的咖啡师，请弄清楚如何与客户建立联系。弄清楚如何创新您提供的服务并使客户满意。经理，创始人和所有者将引起注意。 培养创始人的心态 对于任何创始人而言，最困难的事情是找到具有创始人思想的员工。这是说他们足够在意的一种奇特的方式。 人们会说：“嗯，我不是创始人。我没有得到足够的照顾。” 实际上，您是：通过建立创始人的心态而获得的知识和技能使您成为线下的创始人；那是你的报酬。 您几乎可以从任何职位上受益匪浅。您只需要投入很多。 立即承担责任 Nivi：我们已经讨论了责任制，判断力，专业知识和杠杆作用。如果我从事的是“普通”工作，那么我应该关注的是专业知识吗？ Naval：审判需要经验。建立起来需要很多时间。您必须将自己摆在可以行使判断力的位置。那将来自承担责任。 在您表现出判断力之后，社会才能为您提供杠杆。您可以通过学习诸如编码或与媒体合作等高杠杆技能来更快地获得它。这些是未经许可的杠杆作用。这就是为什么我鼓励人们即使在晚上和周末也要学习编码或制作媒体的原因。 划重点：写代码或制作媒体（如文章、视频、音频等）是非常重要的能力 因此，判断力和杠杆作用往往稍后出现。问责制是您可以立即采取的措施。您可以说：“嘿，我负责这件事，没人管。” 当您承担责任时，您也会公开将自己放在切菜板上，因此您必须做到。 通过对其他人不知道该怎么做的事情负责，您可以建立专业知识。也许它们是您喜欢做的事情，或者自然倾向于做。 如果您在工厂工作，最困难的事情可能是筹集资金以保持工厂运转。也许那就是老板总是要强调的。 您可能会注意到这一点，并认为：“我擅长平衡支票簿，并且对数字有很好的理解；但我以前没有筹集资金。” 您愿意提供帮助，并成为业主解决他们的筹款问题的助手。如果您天生有才干并承担责任，则可以让自己处于快速学习的位置。不久，您将成为继承人。 尽早找到自己感兴趣的事物，并让您承担责任。不用担心短期补偿。当您厌倦了等待补偿并放弃补偿时，就会收到补偿。这就是整个系统的工作方式。 如果您承担责任并在他人无法解决的知识边缘解决问题，那么人们将在您后面排成一列。杠杆将到来。 专业知识技能可能是短期的，也可能是长期的 专业知识有两种形式：短期和长期 如果您一跃成为世界一流的机器学习专家，并且凭借着真正的兴趣而到达了机器学习领域，那么您将做得很好。但是从现在开始的20年后，机器学习可能会成为第二帽子。世界可能已经转移到其他地方。这就是短期的知识。 如果您擅长说服他人，那么这可能是您一生中就掌握的技能。说服他人总是适用的，因为说服人们总是很有价值的。这是长期的知识。 现在，说服是一种通用技能，可能不足以建立职业。正如斯科特·亚当斯（Scott Adams）所写，您需要将其组合在技能栈中。您可以将说服与会计以及对半导体生产线的理解结合起来。现在，您可以成为最佳的半导体销售人员，然后成为最佳的半导体公司首席执行官。 长期的专业知识通常无法教授，并且永远存在。短期的专业知识来去去去；长期的专业知识的保质期往往比较长。 技术是找到那些短期技能的好地方。如果您可以从外部引入更通用的专业知识技能，那么您将获得财富。 技术是获取专业知识的知识前沿 Nivi：推特里还有其他关于该主题的推文。第一：“技术行业是获取专业知识的好地方。前沿始终在前进。如果您是真正的智力好奇者，那么您将比其他人先获得知识。” Naval： 丹尼·希利斯（Danny Hillis）表示，技术尚无法解决的一切。技术无处不在。汤匙曾经是技术。火曾经是技术。当我们弄清楚它们是如何工作时，这种技术就消失了，并成为我们日常生活的一部分。 从定义上讲，技术是知识界。从科学和文化的角度来看，我们还没有弄清楚如何大量生产或有效创造，还没有弄清楚如何将其商业化并提供给所有人。 技术将永远是一个广阔的领域，在这里您可以获取对社会有价值的专业知识。 Nivi：这是来自推特的另一条与问责制有关的推文：“公司不知道如何衡量产出，因此他们衡量投入。以使您的输出可见和可衡量的方式工作。如果您没有责任心，请采取其他措施。” Naval：激励机制来自农业和工业时代，投入和产出紧密匹配。您投入某些时间进行的工作可以可靠地代表您将获得什么样的输出。 如今，工作已经变得非线性。一个好的投资决策可以使一家公司赚1000万美元或1亿美元。产品的一项良好功能可能是产品与市场的契合与完全失败之间的区别。 因此判断力和责任感就变得更加重要。通常，最好的工程师并不是最努力的工人。有时他们一点都不努力，但是他们可靠地在适当的时间发布了这一关键产品。这类似于完成该季度公司大笔订单的销售员。 人们需要能够分辨出您在公司成功中所扮演的角色。人们对别人给予过多的信任极为敏感。您总是想得到荣誉。聪明的人会知道谁负责。 对于这种类型的问责制，有些工作也太远离客户了。您只是一台机器上的齿轮。 咨询就是一个很好的例子。作为顾问，您的想法将通过组织内的其他人传达。您可能看不到高层人士；您可能隐藏在屏幕后面。您要权衡以换取自己的独立性。 承担责任，你就要变得脸皮厚 有责任心时，如果一切顺利，您将获得更多的荣誉。当然，不利的一面是，当事情出错时，您会遭受更多的伤害。当您伸出脖子时，您必须乐于受到指责，牺牲甚至受到攻击。 如果您是那种在高责任心环境中壮成长的人，那么随着时间的流逝，您最终将变得厚颜无耻。你会受伤很多。如果你失败了，人们会攻击你的。 和学徒一起扩展专业知识 Nivi：一旦掌握了一些专业知识，就可以通过培训自己的学徒并将任务外包给他们来扩展知识。 Naval：例如，我进行了不错的投资并找到了创业公司。我本可以继续这样做并赚钱。相反，我与他人共同创立了Spearhead，以训练有前途的创始人成为天使和风险投资人。我们给他们一本支票簿以开始投资。 这是一个学徒模式。他们以他们正在寻找的交易来找我们，我们帮助他们仔细考虑。该模型比我的个人投资更具可扩展性。 专业知识来自工作，而不是课堂 在Spearhead，我们领导班级向创始人教授有关投资的知识，并且我们还举行办公时间，讨论他们带来的具体交易。
2020/3/27
articleCard.readMore百万年薪之间的对话（自由职业者访谈录）
百万年薪之间的对话（自由职业者访谈录） 一开始的标题并不叫这个，而是“百万年薪敏捷教练”的采访。几个标题之间审视过后，还是喜欢现在这个。因为我现在也是百万年薪哦！因此我们来看看2个百万年薪的人之间的秘密吧。 李小波 李小波，资深敏捷教练，极限编程学院高级培训师，自由职业者，3个孩子的爸爸。“成为百万年薪敏捷教练”知识星球球主。 自律、爱家、成事、利他 自由职业访谈 为什么会想到“百万年薪”这个标签 Q（Bob）：为什么会想到“百万年薪”这个标签？ A（李小波）：成为自由工作者之后，没有稳定的工资，所以我会记录自己的每笔收入，也包括知识星球的收入等。在自由职业第一年，工作了179天，统计的总收入为103万（哇！恭喜小波老西） Q（Bob）：你的知识星球主要写哪些内容？ A（李小波）：我会记录自己的职业心得，并为星球内的伙伴解答敏捷中的困惑、问题。欢迎大家订阅《成为百万年薪敏捷教练》 Q（Bob）：能说一下 ThoughtWorks 这家公司吗？ A（李小波）：在社区活动中，很多的分享者（如王宇、乔梁、钱安川等）都是来自于同一家公司（TW）。于是我很好奇这究竟是一家什么样子的公司，我能不能加入？ 2015年经过曲折的面试后，我成功加入这家公司。后来离开创业了一段时间后，再次以培训师的身份加入TW。在 TW 的这段时间中，个人成长很大。 Q（Bob）：刚才你有提到社区，能说一下（敏捷）社区对你的帮助吗？ A（李小波）：可以说社区完全改造了我。从个人、朋友圈、生活及工作。（小波老西对于社区的评价非常高呀）一开始工作时，我只是一个 Team Leader ，在Bob的影响下，参加了敏捷之旅的组织、RSG的组织；并慢慢再社区中开始演讲，产生影响力。 划重点1：小波老西的自由职业者成长路径： Team Leader -> 参与（敏捷）社区（组织者工作） -> 演讲，产生更大影响力 -> 成为自由职业者。 如何参与敏捷社区组织工作？ 私下联系 Bob Jiang 即可 Q（Bob）：能给想成为自由职业者的朋友们一点建议吗？ A（李小波）：成为自由职业者，可以是2个关键步骤：1. 培养自己专长领域的培训（或演讲）能力，这样可以很容易切换赛道；2. 参与社区，并留意社区中的渠道公司（多是培训公司）。 划重点2：社区为王 总结 李小波，小波老西，非常自律的一个人。因此最后小波老西送给大家一句话： 自律带来自信，自信才有自由！ [Youtube视频]() [B站视频]()
2020/3/17
articleCard.readMore7分钟揭晓Scrum的秘密（Scrum框架）
什么是Scrum Scrum 是用于开发和持续支持复杂产品的一个框架。其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则… Scrum (名词): Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付尽可能高价值的产品。 Scrum 是: 轻量级的 易于理解的 难以精通的 Scrum 是一个过程框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的开发上。Scrum并不是构建产品的一种过程或一项技术，倒不如说，它是一个框架， 在此框架 中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和开发实践的相对成效更加清楚地显现出来，因此您可以去改进它们。 Scrum指南 从Scrum指南中我们可以快速总结如下： Scrum是一个过程框架 Scrum框架用于开发复杂产品 Scrum框架帮助人们解决复杂的自适应难题 Scrum能帮助人们高效交付尽可能高价值产品 Scrum框架中可以使用各种不同的过程和技术 因此，Ken Schwaber 曾经说过： Scrum 就像你的丈母娘，不断的指出你的问题。 由此也不难看出，Scrum框架的核心在于不断暴露问题。即它是一个暴露问题的反馈框架。 下面我们来看看Scrum框架中具体包含什么内容。 Scrum 框架 Scrum框架是3个角色，3个工件，5个事件，5个价值观（即3-3-5-5） 3个角色 Scrum的3个角色分别是： 产品负责人（Product Owner）。产品负责人负责最大化产品和开发团队工作的价值。对产品负有最终责任，生杀大权。产品负责人可以决定先做什么，后做什么。 开发团队（Development Team）。开发团队包含了各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。只有开发团队成员才能创建增量。这里所说的开发团队，和我们平时所说的有区别。这里的 开发 指的是产品开发，不是写代码。那么开发团队就会是自组织的跨职能团队。 Scrum Master。Scrum Master 负责根据 Scrum 指南中的定义来推广和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。这个角色没有翻译的中文。但他绝不是项目经理，也不是 team leader 。Scrum Master更像是一个团队的教练。 3个工件 产品待办列表（Product Backlog）。产品待办列表是一份有序列表，其中包含产品需要的一切可能的东西，也是产品需求变 动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。 Sprint待办列表（Sprint Backlog）。Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划。Sprint 待办列表是开发团队对于下一个产品增量所需的那 些功能以 及交付那些功能到“完成”的增量中所需工作的预测。 增量。产品增量是在Sprint内开发团队交付的所有产品待办列表条目的综合。增量必须是符合团队定义的“完成的定义”（Definition of Done） 5个事件 Sprint。也翻译做冲刺，是Scrum的核心，也是一个容器。Sprint是一个时间盒（固定的开始和结束时间），下一个Sprint会紧随上一个Sprint，在这之间没有停顿。Sprint由Sprint计划、每日展会、Sprint执行、Sprint评审及Sprint回顾组成。 Sprint计划。一个Sprint中准备做的所有工作是在Sprint计划会议中完成的。这份计划是整个团队（产品负责人、Scrum Master和开发团队）共同完成的。Sprint计划最主要完成两件事情： 在这个Sprint中要完成什么产品待办列表条目？（What） 如何完成这些条目？（How） 每日站会。开发团队15分钟同步进度并每日调整的一个事件。在每日站会上，每个团队成员回答以下三个问题（基本的，可以根据情况增加新问题）： 昨天，我为帮助开发团队达成 Sprint 目标做了什么?
2020/3/16
articleCard.readMore虚拟引导中的那些坑（陷阱）与小技巧
什么是虚拟引导 虚拟引导（virtual facilitation），顾名思义，不是线下面对面的引导，而是采用线上的方式进行的引导。 虚拟引导，也叫作虚拟会议引导。 如果想成为一名优秀的虚拟会议引导者，你需要精通以下三个领域： 必须知道你正在使用的虚拟会议平台的功能； 应该理解和熟练使用引导优秀虚拟会议的原则； 应该有一个能够使参与者在虚拟的环境中保持专注和高产的参与策略工具箱。 本书通过12章的内容为你提供了实现上述三个目标的路径和各种策略。那些熟悉《引导的秘诀》和《卓越会议的秘诀》的读者将会看到，在这两本书中所描述的具有威力的引导技术是如何进行调整和精简，以适应虚拟环境的。本书分为四个部分，分别介绍了虚拟革命、虚拟会议、应对挑战和虚拟会议示例。经过学习和实践，你将会得虚拟困境所带来的问题的答案，成为高效虚拟会议的组织者和实践者。 – 《虚拟引导的秘诀:在线会议引导的实操指南》 by Richard Smith（理查德·史密斯） [美]Michael Wilkinson（迈克尔·威尔金森） (ISBN: 9787115438454) 虚拟引导中的“坑”（陷阱） Bob 上周参加了 Pepe Nummi 的虚拟引导工作坊，收获颇丰。不敢藏私，在这里把虚拟引导当中可能会遇到的问题整理了一番，分享给大家。 虚拟引导中的“坑”（陷阱）分类如下： 准备不足 引导指令不清晰 培训师风格 参会者的参与不足 不自信 与主题无关 准备不足 准备不足不仅是说虚拟引导，其实对于每一次引导（或培训）都需要事先准备。 而事先的准备会包括以下内容： 工具的熟悉 引导结构（框架）的设计（可以参考 Pepe老师的 CSA结构 - Clarification, Solution, Action） 引导工具的选择（比如力场分析、投票、me-we-us等） 事先演练（dry run） 要提问的问题 只有把以上内容都想清楚了，提前准备充分，才会避免一些意外的发生。 另外针对意外情况，还要有备选方案。 引导指令不清晰 指令不清晰是引导中非常常见的一个问题。比如有人给出的指令是简短扼要，而有人会尝试说了2分钟依然没有提到重点。 所以在准备环节中，可以邀请1-2位小伙伴，进行演练。 先写下你的指令（及要提问的问题） 说给小伙伴听 问问反馈，听懂了吗？哪里有问题 改进自己的指令 一个好的引导指令大致有如下特点： 不要随意发出指令，每个指令都要完成特定的目的 一个指令只做一件事情。如下面邀请小伙伴在白板上写下你的名字…… 尝试用不同的语言描述指令，或者举例示范说明指令 一个指令结束后，要和伙伴确认是否有疑问。（随机抽取一个伙伴的名字提问，忌问全体） 带有时间说明。如下面我们有2分钟，做这件事情…… 用简练的语言，避免口头禅。如那就是说，可以吗，等等 尽可能把指令写到ppt上 部分观点参考于知乎文章
2020/3/9
articleCard.readMore自由职业者6项生存技能 -- 我的自由职业者之路
如何定义自由职业 自由职业 = 自由 + 职业 自由职业是一个组合词，很多人会第一眼看重的是自由，这里我要强调的是职业。 职业就是你（作为个人）的产品，也就是你生存下去的根本。 比如有人是程序员，那么你的产品（产出）是代码；有人是写手，你的产品（产出）是文章。 而自由职业并不是每个人都适合。要看每个人的追求是什么。 有的人追求稳定，有的人喜欢探索；《穷爸爸富爸爸》中有一幅图可以很好的解释职业（如下）： 我们每个人的职业可以分在EBSI四个象限： E(mployee) 职员，这里适合追求稳定的人 B(usiness) 创业，这里非常刺激 S(elf-emplyed) 自由职业，这里也很刺激，介于E和B之间 I(nvest) 投资，这里每个人都应该要做 德雷福斯模型 而每种职业的晋级（发展）基本遵循德雷福斯（Dreyfus）模型。 新手 高级新手 胜任者 精通者 专家 1. 新手 新手最大的特点是，需要指令清单。告诉我怎么做，最好是一步一步的指令。 2. 高级新手 高级新手不想要全局思维。他们会局限于某个部分，而无法看到全局。 3. 胜任者 胜任者能够解决问题。胜任者通常是非常主动，且足智多谋；善于解决问题。 4. 精通者 精通者可以自我纠正。处于这个阶段的人会有很强的独立思考能力，可以自我发现（或通过朋友同事的反馈发现）不足，并及时纠正。 5. 专家 专家凭直觉工作。 – 以上资料摘选自《程序员的思维修炼》第二章（作者：Andy Hunt） 自由职业的6项必备能力 美国现有的职业者中大约30%-40%是自由职业，而中国很快就会成为下一个美国。 无论从收入还是职业发展的情况看。 作为一名自由职业者，必须掌握以下技能才能很好的生存下去： 写作 营销 连接（网络） 英语 财务管理 精力管理 1. 写作 80%以上的自由职业者会时不时的进行写作。可能是推广产品，可能是个人经验分享，也可能是个人的思考。总之是要进行写作输出的。 如果你想要成为自由职业者，那么从现在开始就要练习写作。 种一棵树最好的时间是10年前，其次是现在！
2020/3/8
articleCard.readMoreLeSS案例 Sys商店（大规模敏捷案例分析）
前言 业务敏捷可以定义为一个组织重塑自我并快速适应环境变化的能力。克劳斯.利奥波德在他的书《Rethinking Agile》中提出，人们需要优化交付客户价值的流来实现业务敏捷。通过优化流，你迟早会注意到需要组织结构做什么样的调整来加以支持。 首先，关键是理解敏捷的真正含义，就像敏捷宣言中构想的那样，它并不是组织交付客户价值的速度，而是组织以低成本快速响应变更的适应性。（参阅《Scaling Lean & Agile Development》中 _Be Agile一章）。利奥波德对于组织变革还有这样一个观点：在持续地关注系统优化目标时，人们会注意到那些阻碍改进的因素。然而通过系统思考，长时间在实地的观察和实践，对现存系统动态的反思，人们也可以预见到那些阻碍快速适应能力的相对明显的现存组织障碍。在这个故事中，一个组织学习并最终看到影响大规模适应性的组织障碍，它经历了漫长而痛苦的过程。更糟糕的是，很多管理层试图保持传统管理现状而仅仅将事物标记为”敏捷”，而不是去预见 - 或者愿意去预见 - 相对明显的障碍并在一开始就进行必要的变革。简而言之，这个过程恰恰反证了LeSS中的关键导入原则（“对于产品团队，要在一开始就建立LeSS的组织架构，这对导入LeSS非常关键”_）以及由此带来的后果。 所以，接下来的案例说明了，如果组织没有在一开始进行合适的组织设计，会发生什么情况。从开始的传统组织架构和管理方式入手，可能混有一点伪Scrum元素，LeSS要求的组织设计_也许_会浮现。但这将会是一个更长、更危险的旅程，因为它可能不会带来导入LeSS所预想的好处。为什么？因为一旦没有立即采用新的组织架构，那股保持组织现状的强大力量极有可能会获胜（参阅拉曼组织行为定律）。 本案例的关键”反事实”洞察：如果你想开始业务敏捷的旅程，期望减少过程中的许多痛苦，并快速获得LeSS所预期带来的适应性上的提升，一定要在导入LeSS的开始阶段就建立合适的组织结构，就象LeSS规则所倡导的那样。 开始之前的评注 LeSS就是（多团队的）Scrum，Scrum就是单一团队的LeSS。（参阅原则：大规模Scrum也是Scrum）。为了让本案例中的描述更加准确，我还是会澄清哪些是Scrum指南中的规则，哪些是LeSS指导方略中的规则。在参与这个案例的过程中，我受到less.works网站的积极影响，参加了Bas Vodde和Craig Larman的LeSS实践者课程，并花费了大量时间阅读最初出版的两本LeSS书籍。可惜的是那时第三本书还没有出版。在这个案例中，我阐述了我们尝试过的LeSS实验，并且也会关联我们遵循的LeSS原则、规则和指南，尽管那时并不知晓。 简介 下面的案例涵盖了我从2015年2月到2016年9月在一家公司Sys的IT组织做外部教练的时光。Sys是一家来自德国的从事软件行业的跨国公司。因为我已签署保密协议，所以不能在此公布公司的真名和其他相关的公司信息。时间回到2014年底，Sys着手用一个平台来变革公司软件销售方式，取代现有各种外部合作伙伴平台。这个平台的诞生标志着Sys迈入电子商务新途径的里程碑，不仅重新思考了如何直接地向客户销售软件，还重新定义了卖什么（例如，除软件以外的数据）和怎么收费。 这背后的想法是创建一个网上商城，客户可以通过最小的交互，从Sys或是其他第三方软件发现、尝试和购买软件、内容和数据。目标是通过电子商务产品”SAP Hybris Commerce”来提供像亚马逊一样的简单流程，同时涵盖多样的产品部署（就地部署和云解决方案），支持不同的支付方式（信用卡和PayPal）。 2011年，我曾在负责所有内外部平台的Sys IT部门工作过，这些平台跟Sys商店很像，那时我们整个部门开始将瀑布模式替换成Scrum。在用（单团队）Scrum的方式搭建了两个平台之后，我离开了这家公司，去支援其他客户的敏捷之旅；在2015年的早期，我又重新加入Sys来支持这次重要的旅程。 变革之前 系统架构 在我加入的时候，有四个团队并行工作，研发新功能或者增强现有平台，并用固定的时间表合并代码，然后进行好几周的集成测试和验收测试。系统格局是一个复杂的三层结构，包含基于Spring框架的主要J2EE应用程序平台SAP Hybris Commerce，用于存储数据的SAP Hana 数据库，基于SAP PI服务器与SAP ERP和SAP CRM的同步，还有额外的第三方服务用作分析、处理信用卡支付或用户生成内容的集成。 变革之前的组织结构 图3是组织结构。有三个开发团队，两个在欧洲一个在美国，并行工作在系统的不同部分。还有一个架构团队，负责新特性的软件整体设计，以及一个测试团队，在不同团队的代码合并之后进行集成测试。此外，另有一些后台开发（SAP ERP/CRM）专家、DevOps专员和UI专家，他们没有加入任何研发团队，而是建立了自己的团队。欧洲的团队成员（随机地）分布在德国、波兰、西班牙、爱尔兰和保加利亚。这是因为Sys只有六名公司正式员工，其他所有团队成员均来自于专门从事SAP Hybris研发的第三方供应商。 除了技术团队，还有一个超大的业务组织来支持软件的研发和运营。在第一层，经理们带领一个小团队来进行特性的优先级排序、编写蓝图、执行用户验收测试并启用功能。在第二层，又有一个团队专门负责整个产品组合、需求排序以及业务方用户验收。在第三层，是由三个项目集经理组成的项目集管理，一个来自业务（Sys Digital），一个来自Sys IT，还有一个来自Sys Education的项目总负责人。另外，还有一个支持项目集管理的项目和质量管理办公室。为了跟踪研发和业务的进度，每周还有工作流周会，干系人状态周报，以及从项目办公室汇集到管理团队的书面项目集更新。 痛苦的最后期限和变革的必要 当我在2015年2月底加入时，平台基本上已经可以使用，只差正式宣布。各团队还在冲刺最终官方发布日期：2015年5月5日。到时候公司会在美国举行有史以来最大的会议，首席数字官会当场向公众演示这个平台。所有正在研发的功能都是官方需要发布的功能，所以，项目办公室制定了一个看起来能在5月2号发布所有功能的严格的项目计划。该计划包含了研发阶段、系统集成阶段，用户验收测试以及回归测试，就像我们通常说的瀑布模式。 在三月的最后两周和整个四月项目进入一个动荡期。时间表正渐渐延期。当并行工作在不同功能的团队将他们的代码合并到主代码仓库后，很多之前已经测试通过的功能不再能使用或者表现异常。不停修复这些问题又带来新的问题，并且还经常突然接到必须立刻实现的新需求。在此之上，之前从未考虑过的安全问题和负载测试现在也必须解决。管理层变得十分焦虑，每个人不得不工作更长的时间来尽量满足计划。在四月的最后两周，还建立了一个”作战室”，所有的经理、团队负责人和架构师都在这个房间从早到晚不停的清理障碍以保证发布的所有准备工作都做好。最后，开完数不清的升级会议和成百上千小时的加班之后，团队终于能够在大会的第一天发布平台的新版本。 经过了如此痛苦的发布，对管理层来说，毫无疑问现有的研发方式已经不能支撑公司的雄伟目标，那就是销售指数级增长，能快速尝试新的商业模式和推出完全不同的产品。Scrum作为一个敏捷研发框架，专注于首先交付最高业务价值，持续关注透明性、检视和调整，这些都建立在基于经验过程控制的理论之上，它成了一个自然而然的选择。然而要导入Scrum或者LeSS都被认为极其困难，不仅仅是因为组织层级设置和对分散在不同地方的各种技术专家的依赖，还受到巨大营销渠道的影响，即每年有两次不可更改的作为大里程碑的重要峰会。 引入变革 作为一个偏好大规模Scrum的经验丰富的敏捷和Scrum教练，我被要求建议”研发部门”应该如何改变工作方式以应对当前的挑战。 我的挑战因此是（1）让所有人都意识到为了应对挑战_不只是研发部门而是整个组织要改变_；（2）帮助参与者_通过理解为什么_来拥有变革背后的想法，而不只是跟随我的想法遵循我的建议而已。 在一次上层管理者（包含Sys首席数字官）的会议中，我展示了从和业务和研发代表的对话中收集到的关于挑战的总结。它包括： 业务挑战（摘录） 单个特性和产品能力的优先级不明确 _明确标注_已完成的工作在后期出现问题 技术挑战（摘录） 可用性和基础设施问题（性能，端口关闭等）妨碍了日常运行 整个部署流程耗时太长。常常缺少某些部分（模版，后处理等） “架构师”们忙于做构建流程、合并代码、以及基础设施的建立/配置这样的手动任务 使用各种分支而不是基于主干的开发，导致代码合并的工作量巨大；并且质量很低，有许多缺陷/问题 测试数据的的创建是一个非常耗时的过程并深受知识缺口的影响 在准备这个会议的过程中，我还收集了管理层的整体改革目标。基于与管理团队成员一对一谈话和访问，我总结了如下几点：
2020/3/1
articleCard.readMoreSita - 边境安检 LeSS案例 （大规模敏捷案例分析）
边境安检系统：LeSS与离岸开发 背景 背景与客户 SITA创建的产品可帮助全球各地政府确保边境安全。我们正在创建的产品是用于自动化边境的解决方案，以在不影响安全性的前提下优化前往各个国家旅行者的流程。该产品是这样构建的，获取前往相应国家的所有旅行者数据，根据可用的监视列表对每个旅行者进行筛选，并针对被政府机构（例如，警察、移民等等）用系统标记的旅行者采取并记录必要的行动。 原文链接 开始 2010年SITA赢得了一项为期18个月的大合同，以创建和实施边境安全系统。该系统包括高度安全的数据中心和部署在该国所有口岸的软件解决方案。 Frank West（产品交付总监）聘请我为内部顾问，来帮助他们采用敏捷的工作方式。 双方之间的合同是构建整个系统（产品和数据中心），并在18个月后以一次性的方式进行部署。但是软件开发总监对这种方法感到不安，因为过去他多次在一次性交付中吃过亏。这次的情况尤其如此，因为该系统非常复杂并且由许多未知数组成。因此，他想（再次）探索敏捷的工作方式，并雇用我来帮助他以迭代、增量和自适应的方式交付该系统。 我加入时，SITA的组织结构非常等级化，划分成独立的职能部门。看起来像这样： 业务团队存在类似的结构，主要由项目经理、销售顾问和业务解决方案架构师（主题专家SME）组成。 向Scrum过渡（但不是LeSS） 我们从为期三天的研讨会开始，了解敏捷宣言、敏捷原则及Scrum。从正确的教育入手至关重要。我们想确保建立一个长期的学习型组织，因此我们将重点放在激发与提供适当的教育方面，以实现更多的协作、迭代和增量式的工作方式。我提供了Scrum概述的培训，然后我们讨论了如何组建开发团队。在与开发团队和管理层进行了大量讨论之后，我们提出了如下的团队结构： 对我们而言，从一开始就建立适当的结构非常重要，以确保我们创建真正的团队，同时牢记“文化遵循结构”，这是“拉曼的组织行为法则”的第五条的一部分，因此我们首先创建了两个跨职能的Scrum团队。这些团队由SME、BA、开发人员、测试人员和架构师组成。尽管我们的确是由一组专家组成的团队，但每个团队成员只有一个头衔即“开发人员”。对团队的承诺和期望是他们将不再担任专家，整个团队将朝着Sprint目标努力，并选择实现Sprint目标所需的下一个任务。 我们的主题专家（SME）人才是边境控制流程和航空业的高技能领域专家。 我与弗兰克（Frank）讨论过，我们不需要项目经理，但他还是坚持要求保留两个人（项目经理和解决方案架构师）来管理公司报告和一些售前活动。他们俩都对要出售给客户的产品有很好的领域知识。 弗兰克（Frank）明白，将来我们不再需要这两个“角色”，但是他建议保留这两个人的角色，在目前将有助于我们跟销售团队就一直在开发的产品保持同步，以便让他们不要将其作为单独的“项目”出售。弗兰克要求他们两个都与销售团队工作，并且他们也定期与产品负责人工作，以了解我们产品的进度，以便他们可以相应地为我们的潜在客户提供建议。 我们继承了组件团队 从总体上讲，整个解决方案是从航空公司收集每位乘客的数据，并根据观察列表对每位乘客进行筛选，以了解是否有不受欢迎的人试图访问该国。该解决方案主要分为两大部分：数据获取系统（DAS）和风险评估系统（RAS）。所以团队也是按这一结构来创建。Black团队（每个团队用颜色来命名）负责获取数据，Green、Blue和Purple团队负责风险评估（译者注：与作者确认最开始只有Green团队）。因此我们从组件团队开始，当时看起来很“合乎逻辑”。 从组件团队到特性团队 最终，我们意识到组件团队在团队之间引入了许多不必要的依赖与移交，这导致了迟来且昂贵的反馈，在整体回顾中我们也讨论了这些反馈。使用这些反馈，我们开启了以避免不必要的依赖的从组件团队转向特性团队的对话。在对话期间我们还意识到，如果我们不尽快转向特性团队（跨团队管理依赖关系将是一场噩梦），将来很难有效地添加更多团队，因此我们开始讨论创建特性团队的方法。 在对话期间，团队还提出了组建特性团队的如下问题： 并非每个团队都有实现下一个优先级条目所需的技能和知识 跨不同架构组件的特性实现的设计可能会变得混乱 特性团队可能会卡在设计决策上 所有这些都是重要点，因此我们决定从一个特性团队开始（“*指南：过渡到特性团队*”），而不是大张旗鼓。我们创建了一个特性团队，并要求他们端到端地交付特性。我们遵循XP（极限编程）的建议，为每个组件引入了“组件牧羊人（Component Shepherd）”作为导师，以避免最初出现任何技术故障。 “组件牧羊人”的主要作用是指导特性团队改动相应的组件，并在团队进行改动时提供利弊对比。所有牧羊人都更像旅行者（“*指南：旅行者*”）那样工作，因此他们大部分时间都可以自由地辅导和指导多个团队。团队逐渐地（9-12个月）积累了多个组件的知识，从而很少再需要“组件牧羊人”的指导。 过渡到LeSS Scrum的实施对我们最初的两个团队工作良好。我们提供的最初产品收到了客户的良好反馈，从而引起了其他潜在客户的极大兴趣。我们的潜在客户喜欢我们交付的特性，但他们也希望产品中有许多新功能。一旦有更多的客户注册了我们的产品，我们就决定增加更多的团队。 我们没有多团队合作的经验，因此开始探索可用于帮助我们的资源。我们发现了两本书，分别是Craig Larman和Bas Vodde撰写的《*精益和敏捷开发大型应用指南*》和《*精益和敏捷开发大型应用实战*》。对于我们的案例，它们看起来像是完美的指南，尤其是关于大规模Scrum框架2（现为巨型LeSS）的概念，因为我们预计将来会增长到大约20至30个团队。 这些书籍在提供有关规模化（以及由此对组织提出的挑战）的准则方面如此丰富（现在仍然如此），以至于它成为我们在整个过程中进行规模化的指导力量。我们开始定期探索这些书中的想法，并进行了一本书中的许多“*尝试和避免……*”的实验。 多地点的离岸开发 尽管我们强烈推荐在同一地点办公，但我们在当前办公室的物理空间仍然受到一些组织上的严格限制，并且需要与位于不同时区的客户进行互动。当我们要求管理层（执行委员会）提供额外预算（主要是更多的团队）时，他们要求我们与位于印度和基辅的现有离岸合作伙伴进行合作，以确保我们在多个时区都有团队存在（主要是中东和澳大利亚）来吸引和支持我们的新客户。 我们接受了挑战，但有一个条件，即一旦选择供应商，我们将像在英国一样进行面试和组建团队，而不是接受下一个可用人员或团队的典型离岸模式（“*避免……外包商说，交给我们吧，我们为您做到敏捷*”）。我们还决定在每个地点都有一些位于同一地点的团队（“*指南：在LeSS中组织多地点办公*”），以确保团队之间能够相互学习，这只有在同一地点的团队中才有可能。我们还将把离岸团队带到英国至少进行4次Sprint（“*尝试……离岸之前先在一起进行几次迭代*”）。 我们以为在管理方面会遇到困难（基于过去的类似经验），但是令我们惊讶的是，在开始离岸供应商选择流程之前，我们的管理层和离岸合作伙伴都毫不费力地达成了一致。我认为他们了解过去离岸团队的加入一直很痛苦。但是当他们意识到我们一直在以新的工作方式交付成果时，他们允许我们尝试与离岸团队合作的方式。 我们办公室内的多地办公体验 我们与团队讨论了多地办公的试验，并确保不会对他们的工作产生任何影响。因为他们也知道我们需要更多的团队，并且对物理地点有很大的限制。尽管大多数人都有多地办公的经验，但这不是我们最近的（检视和调整）工作方式。在对话中，一名团队成员问，在敏捷环境中与多地的团队合作感觉如何？由于我们都没有与多地敏捷团队合作的想法，因此团队中的一位成员给了我们一个想法，即我们在其它地点加入新团队之前，先要经历多地环境的挑战。她建议“为什么不将现有的一个团队搬到另一楼层，而仅使用电话或Skype与另一团队进行沟通，即 没有面对面的交流，看看这带来了什么挑战。我们非常喜欢这个想法，它与书中的一项实验一致（“*尝试……即使位置靠近也按多地思考*”） 一个团队在下一个Sprint搬到的另一楼层（幸运的是，我们在那层上有一个可以容纳团队的空间，但只能用2周）。很快，我们可以看到，即使他们位于同一栋大楼且只有一层之隔，团队也意识到了多地办公向他们施加的挑战。尽管他们已经合作了很长时间，但是无法看到他们，只能通过电话、电子邮件和Skype进行交流，他们还是因此失去了紧密的物理协作（例如白板会议）。 这是一个很好的实验，可以为即将到来的“离岸团队”建立“现场”团队的同理心（这就是他们一开始的看法）。 离岸合作伙伴的选择 我们访问了三个地点（印度两个，基辅一个），并受到了所有人的热烈欢迎。 这些人都从大量的Powerpoint演示开始，介绍了他们的“敏捷”能力和已交付的“敏捷项目”的经验。 很快就很明显，他们对敏捷工作方式的大多数理解都是“错误的”。一次又一次的演讲，很明显这些团体要么是在大肆宣传，要么是对他们所说的“敏捷”一无所知。我们认为他们在“创建Powerpoint幻灯片”方面要熟练得多，但通过交付迭代和增量的软件来交付持续的价值呢？不见得行。 我们想知道为什么他们对敏捷的工作方式没有这么了解。毕竟，这些公司可以访问所有内容（培训、书籍、聘请顾问和教练等以帮助他们）。我真诚地问了他们的一位经理，以便从他们的角度来理解这个问题。他的回答非常有趣且提供了有用的信息，帮助我们了解了离岸IT公司的工作方式。总而言之，离岸公司不向客户提供咨询服务。他们的商业模式通常围绕以低廉的成本提供人员，并与客户期望他们工作的方式保持一致。因此，他们不会真正地投资任何新事物，直到成为主流，并且客户希望他们对新事物有所了解。 在拜访了所有离岸候选人之后，我们意识到这将是一个漫长、痛苦而又令人兴奋的旅程。因此基于跟他们的经历，我们建议仅从印度班加罗尔的那个团队开始。按照《精益和敏捷开发大型应用实战》（“*尝试……更少的地点*”）一书中的实验，我们不想从多个离岸合作伙伴的多个地点开始，以创建不必要的复杂性。 “商业部门”推动我们同时使用这三个地点。但是，当我们向他们解释了多个地点及多个合作伙伴的负面影响（沟通、协调失灵、语言和文化差异、与其中一个地点的签证问题等）之后，尤其是在敏捷开发环境中，我们被允许先选其中一家，但他们还是期望将来可以用所有的三个地点。 除了上述提到的多个离岸地点的负面影响之外，我们还希望保持组织的简单性，并继续我们*成为敏捷(be agile)*而不是*做敏捷(do agile)*的旅程。我们已经在Scrum和Extreme Programming工程实践方面有了一个良好的开端，我们希望增加更多的团队，但不增加任何不必要的协调、离岸管理等开销，以保持以客户为中心。基本上，我们希望通过消除客户和团队之间任何不必要的复杂性来简化组织，从而扩展产品的开发规模。在成功试验两个地点（英国和另一个地点）之前，我们致力于避免不必要的、人为的管理多个地点的复杂性。我们深知与离岸IT公司合作会带来不必要的开销，例如与项目经理、现场协调员、离岸项目经理、多个时区等打交道。 当我们自己试图简化组织设计保持以客户为中心时，我们理解了为什么“商业部门”会迫使我们选择这三个地点。高层迫使他们将新工作移至离岸地点以降低成本。他们表现得像一个会计师（还是一个很好的会计师），却不了解其行为的整体系统含义。简而言之，这是经典的*局部优化*。 我们部门的业绩在整个组织中引起了积极的反响。我们的成功故事（高质量的产品、满意的客户、提早交付和持续交付、更多的业务等等）也触及到产品开发外部的各种人员（例如HR、商务等），他们对我们不同的做法感到好奇。我们邀请商务部门的人员与我们的团队会面，以便向他们解释我们的工作方式。这与LeSS的采用规则有关：“*对于产品组以外的大型组织，请使用现场现地（Gemba）来采用LeSS演进，创建以实验和改进为准则的组织。*”。访问我们的时候，他们惊讶地看到我们在部门内创建的可视化效果。他们可以轻松地查看我们的产品待办事项列表（墙上的故事地图），每个团队的Sprint待办事项列表（白板上），构建的统计信息（构建状态，缺陷数量等），监视器等，以及在地板上合作（主要是人们一起工作的噪音）（译者注：在地板上合作指的是大家走来走去，面对面的沟通）尽管来自非技术部门，但他们的反应是您为什么不采用这种方式工作，这是如此明显。他们还真心想帮我们跟离岸供应商协商一个更低的价格，如果我们愿意直接与10多个团队工作的话。我们礼貌地拒绝了，并意识到我们还有很长的路要走，以使我们的组织精益化和系统化思考。他们显然看不到增加10多个团队相比于1个团队来说的系统影响。他们只是从自身降低成本这一局部优化目标来看，而没有意识到这样做可能是增加了总体成本。 我们与离岸合作伙伴约定的条件之一（在我们决定与他们合作之前）是我们寻找“长期合作伙伴关系”，而不是临时的项目方式（“尝试……将离岸组织视为内部合作伙伴 ”）。实际上，这意味着： 我们将采用相同的工作方式（如Scrum和XP中的工程实践）和 相同的团队组成（跨职能和自我管理）。 我们还提供了帮助，以Scrum、XP和精益思想为基础，让离岸管理人员理解和适应工作方式，这样做我们实质上是忽略了组织边界。我们说过，我们将在最初的3-6个月内提供一名教练，以帮助他们建立和完善对精益思维和敏捷工作方式的理解。这位敏捷教练的费用不需要他们承担，因为我们将这视为与他们建立长期可持续伙伴关系的投资。
2020/3/1
articleCard.readMore宝马集团 LeSS案例 （大规模敏捷案例分析）
巴伐利亚汽车制造商的LeSS转型 背景 Valtech德国公司是选中的供应商，以帮助其应用敏捷开发来创建宝马集团的新*BMW i*汽车的直销流程。这需要新的IT支持系统，所有这些系统都已嵌入到现有的IT环境中，其中80多个系统会受到影响。有一个跨越许多项目的大型项目集来创建新的支持系统。 其中一个项目是新的统一销售平台（USP）系统。USP从头开始实现，集成了30多个外部系统接口。*BMW i*推出的其他合作伙伴项目，仍沿用非敏捷过程模型。因此，跨项目的共同里程碑、报告和协作成为一个挑战。 经过2年多的开发，USP按时发布，并具有很高的质量和客户（比利时-荷兰-卢森堡市场）满意度。 阶段1：在多个特性团队之前 2012年2月，USP在充满挑战的环境中开始开发： 时间压力大，因为上线日期已经确定 直销业务流程仍在讨论中，尚未定义 因此，USP产品的范围还不清楚 大多数参与者不熟悉宝马集团的业务、销售流程及敏捷方法 USP项目嵌入在传统的项目集（*BMW i*项目集）管理系统中 由于上述情况，USP项目决定使用Scrum和敏捷工程实践，来尽早和持续地获取有关产品进度和组织进度的反馈。敏捷开发从一个Scrum团队开始。这个团队建立了合适的敏捷开发流程，搭建了合理的开发基础架构，找到了与业务部门的协作模式，并为敏捷开发奠定了坚实的基础。 这个最初的团队评估了所需的工具，搭建了开发环境和持续集成系统，尝试了不同的Sprint长度，并实现了第一个业务功能，验证了新组织是否可以正常工作。 从第一个Sprint开始，USP团队在每个Sprint结束都演示了可运行的和经过测试的软件。 后来，团队增加了一些人，这些人以传统的职能和组件团队的结构进行了组织，这代表了更广泛的*BMW i*项目集中使用的标准模型。 在USP 1.0版本之前团队一直在使用这种结构。 阶段2：转变到多个特性团队与LeSS 当前的组织结构对发布1.0版本来说已经够用了。不过，作为教练我们预见到，对于下一个更大的版本，这种组织结构的扩展性不好。团队需要更灵活（敏捷），因为优先级和需求经常变化。团队需要能够从产品待办列表中选择不同的条目，并交付完整的端到端特性。此外，还需要减少特性的周期时间以缩短“上市时间(time to market)”。 在先前的组织中，团队只能做一种类型的功能或特定的组件工作。这限制了更改产品待办事项的优先级和团队灵活地“转到新工作”的能力。而且，专家小组间的交接和延误，延长了平均周期时间。此外，还增加了协调和集成的工作量和问题。 因此，根据我们的建议，团队同意重组为多个特性团队并同时采用LeSS。 我们的目标是创建五个新的跨组件和跨职能的特性团队。 由于现有的商业合同和项目集的政策，USP项目组无法完全重组为特性团队。例如，有一个UI设计治理小组负责整个程序的UI一致性。还有一个测试管理团队，负责协调项目集范围内的跨项目测试活动，并为整个项目集提供报告。这个团队不做测试工作；测试工作仍由实现团队自己完成。不过，测试管理团队对（实现团队）“未完成（undone）”的部分做出了贡献，例如组织外部公司做渗透（安全漏洞）测试。此外，按照项目集政策，这里还需要一个项目管理团队，汇报给上层的（传统）项目集管理团队并负责人员、设施和设备管理。 图 1: 阶段2的USP项目的组织结构 自设计特性团队工作坊 我们还达成一个共识，即通过*自设计团队工作坊*（LeSS实验之一），重组为特性团队。 团队花了3轮的时间（每轮20分钟）形成了符合愿景的组织：所有特性团队应能够独立处理所有利益相关者/请求者的产品待办事项。 在组建新团队后，他们创建了新的团队名称，找到了自己的团队空间，选举了Scrum Master和“首席”开发人员（由于政策原因，这仍然是必需的角色）。 整个团队的自设计工作坊大约持续了三个半小时。 有关自设计团队工作坊的详细信息，请点击此处 团队建设工作坊 自设计团队工作坊是一个很好的开始。但是在自设计团队工作坊结束时，有一些新成立的团队，他们必须应对新的动态。根据LeSS的说法，向特性团队的转变是对旧系统的重大更改。该项目组面临着两方面的扩展。一方面是跨团队协作，按照一个产品待办列表的优先级与所有团队合作。在LeSS环境中，Sprint仪式和同步会议覆盖了这一方面。第二方面与团队内的可用知识有关。所有团队都让团队成员了解不同的组件。这体现了团队中的一个瓶颈，因此这种情况是扩展的障碍。为了在系统层面上进行改进，需要改善团队内部的知识共享。另外，项目管理团队的目标是尽快使这些新团队重新发挥作用（尽快开始工作）。因此，项目管理为每个团队提供了进行额外的团队建设工作坊的机会。本次工作坊的目的是降低社交障碍，启动知识共享措施，寻找工作协议并在团队挑战中反思团队动力。 工作坊日程： 时长 主题 00:05 介绍、日程 00:10 破冰练习 00:30 团队知识模型 (agile world 2013) 00:45 一致同意的措施 00:30 团队愿景和团队章程 00:50 团队挑战 (室外) “有毒废料Toxic waste” 00:10 结束和反馈 03:00 社交：午饭或晚饭 {: .
2020/3/1
articleCard.readMore少即是多 - 组织简化的7个设计原则
作者：(Bas Vodde and Craig Larman) 译者：Bob Jiang 审校：本洋 少即是多： 组织简化的7个设计原则 为什么采用敏捷或LeSS？许多组织的目的是提高个人生产率或团队生产率，提高活动、产出、速度或资源利用率，不幸的是，却没有意识到这通常会导致整体价值交付的*降低*、客户功能周期时间变长以及适应性降低。LeSS并不专注于局部优化（例如提高个人生产力），而是*优化组织*以最大程度地提高客户价值交付和组织敏捷性（适应性），即组织成员可以轻松、快速地根据学习*改变*方向。 如何实现敏捷、灵活、适应性强的组织？通过创建*更简单*的组织！ 具有许多角色、流程、部门和工件的复杂组织适应变化的速度很慢。简单的组织具有快速适应的潜力。在LeSS社区中，我们称此为简化(descaling)组织的复杂性。这是LeSS原则的精髓之一，即*少即是多*原则。 我们如何设计更简单、更敏捷的组织呢？使用以下组织设计原则来简化成为LeSS组织： 从*专业角色*到团队 从*资源思维*到人才思维 从*围绕技术进行组织*到围绕客户价值进行组织 从*独立团队*到持续的跨团队合作 从*协调集成*到通过集成进行协作 从*项目*到产品 从*许多小型产品*到少数几种广泛的产品 1. 从*专业角色*到团队 传统组织具有一些单一的专业角色，并详细定义了这些角色之间交互的流程。每个人负责他们自己的专业。他们因此被公司雇佣，并可能其一生都从事此专业领域。当所有个人都履行其确定的角色时，组织绩效将得到最大化。理论上是这样，但适应性很可能较低。 LeSS组织的团队负有共同责任，即实现以客户为中心的目标-通过自我管理，他们自己决定如何工作以及由谁来完成。团队成员不会陷入通才或*单一*专家的错误二分法（译者注：Alternative 二分法即非此即彼的方法）中。人们天生有喜好，但他们不会局限于一个专业。随着这些职责成为团队职责，许多专业角色（例如测试人员、交互设计师或业务分析师）将不复存在。广泛的责任感和自我管理提高了适应能力。 2. 从*资源思维*到人才思维 传统组织假定个人的技能是相对固定的，因此将人作为资源来管理。传统组织结构的目的是最大程度地利用这些资源，以提高个人生产率。这需要大量的管理工作来解决这些复杂的资源分配。 LeSS组织把人作为人来管理，并认为个人的最强大技能是*获得技能和发展技能*。LeSS组织结构的目的是故意让现有技能和知识与所需的技能和知识不匹配，以增强适应性。这就需要人们学习，这样既带来欢乐又带来不舒适。但是所有复杂的资源管理都消失了。 3. 从*围绕技术进行组织*到围绕客户价值进行组织 传统组织围绕其技术构建组织。许多人以自己的技术专长来凸显自己，围绕技术进行组织似乎可以最大化他们的个人生产力。交付客户价值通常需要不止一种技术，这会造成额外的协调工作并降低了适应性。 LeSS组织围绕客户价值构建其组织。深入了解客户是至关重要的，这样才能用技术解决“他们的”问题。通过围绕客户价值构建组织可以让团队离客户更近，从而加深对客户的理解，这样会让适应性更强和客户价值更高。 4. 从*独立团队*到持续的跨团队合作 传统组织倾向于独立团队，团队专注于产品中自己的部分。这些团队避免工作不停被打断的方式是定义清楚的接口，其他团队必须遵循。更改，审查和批准流程避免了对这些接口的频繁更改。通常，通过隐藏、延迟真正的依赖关系才能实现独立性。团队之间的这种割裂降低了组织的灵活性。 LeSS组织倾向于多个团队拥有共同的工作。这些团队不断合作，为一个始终如一的产品做出贡献。尽管每个团队都有自己的目标和身份，他们还是像一个大团队一样运作。更改，审查和批准可以大大被简化甚至消失。 5. 从*协调集成*到通过集成进行协作 传统组织进行协调以整合（集成）许多团队的输出。由于团队“异步”交付其输出，因此协调的责任在团队外部，从而导致协调角色（例如项目经理或发布经理）和协调事件。协调冲突很常见，会导致重新评估优先级和调整优先级。 LeSS组织的团队不断整合（集成）他们自己的工作。通过不断的集成，团队发现了跨团队协作的机会 – 一个令人惊讶且强大的想法。由于跨团队集成具有同步性，因此团队现在可以同时共享工作，还可以将协调责任融入到团队中。团队外部的协调角色消失了。 6. 从*项目*到产品 传统组织将开发工作作为项目或*项目集*（大型项目）进行管理。项目的开始日期和结束日期明确，范围明确。人员被按照预定的时间分配给项目。预算由预定范围的期望值决定。这样几乎没有余地来响应变化。多种多样的项目导致了复杂的项目组合管理，以同步对项目进行资源重新分配。 LeSS组织将开发工作以产品进行管理。产品用途明确，但没有固定的结束日期或固定的范围。人员被分配到产品中，但没有预定好的时间长度。预算由潜在价值决定，而不直接与具体范围关联。这为响应变化留出了很大的空间。产品是持续进行开发的，因此按规律节奏把人员分配到产品就足够了。复杂的项目组合管理消失了。 7. 从*许多小型产品*到少数几种广泛的产品 传统组织倾向于管理基于技术的小型产品，例如服务、组件、应用程序或平台。但是，没有一个小型产品是孤岛，它们需要交互并集成在一起才能带来客户价值。这导致了复杂的跨产品管理结构，以用于协调、排优先级和制定预算。 LeSS组织倾向于管理以客户为中心的广泛产品。服务、组件、应用程序和平台属于同一产品，其中只有一份产品待办事项列表和一个产品负责人。团队创建以客户为中心的功能，并跨组件工作。复杂的项目组合管理消失了，复杂的跨产品管理结构消失了、或者变得非常简单。 每个组织设计的选择都需要组织思维的巨大转变，并且这对人员、团队、组织结构和管理都有很大的影响。这些变化并不总是那么容易，但是它们可以带来更简单、更具适应性、更有目的性和更有趣的组织，这样的组织能交付更高的价值。
2020/3/1
articleCard.readMore德国大保险公司（化名） LeSS案例 （大规模敏捷案例分析）
德国大保险公司（化名）的巨型LeSS转型尝试 介绍 本案例研究描述了一个部门从最初采用Scrum到LeSS Huge的转变。迈向LeSS Huge的那些步骤包括但不限于： 部门的重新设计 建立需求领域 引入LeSS事件 引入描述需求的新方法 重组产品待办事项列表 本案例研究首先简要介绍了背景，试用阶段（2016年夏季-2016年12月，当时我不在场）以及最初采用Scrum的过程（2016年12月至2017年3月），在此期间我曾经指导了该部门。 LeSS的大规模采用始于2017年4月，并进行了更深入的描述。我一直在全职工作，直到2017年6月。此外，我还吸收了开发主管和其他成员在2018年夏季之前的反馈。 目的 本案例研究的目的是对部门中试图实施 LeSS Huge 有一个批判的视角。尽管已经取得了很多积极的成果，但案例研究还是有目的地强调了问题，并讨论了原因和结果，因为与“平滑”转型相比，这通常会使人们对组织变革的动力有更多的了解。因此，请勿将此描述视为“最佳实践”;） 背景 大多数人都有某种形式的保险。为了更好地理解这个案例的背景，我将以奥托（Otto虚拟人名）为例说明一些相关方面。奥托拥有几项保险，例如人寿保险、家庭保险和旅行保险（保险供应商Sampo提供的）。奥托想购买一辆新车，然后去他选择的汽车经销商处。他买到了梦寐以求的汽车。另外，作为销售套餐的一部分，经销商提供了各种汽车保险。这就是本案例研究中称为B2B2C（车辆保险）产品的内容。奥托购买了责任险，并高兴地回家了。他希望一目了然地查看所有保险，为此，他登录了提供此视图的保险公司网站。提供查看的数据来自于“公共数据库 common database”（本案例中我起的名字）。 *Terra*部门隶属于一家超大型的德国保险公司Alpha1。*Terra*负责产品的开发及其运营。他们在其职责范围内创建了两种类型的产品，如下所示分别为“B2B2C”和“B2B”的车辆保险。 B2B2C产品是德国的车辆保险，而B2B产品是代理商的国际保险服务。B2B2C产品是基于现有车辆保险产品的变种，此外，B2B2C产品使用了一个公共数据库（包含企业和消费者的数据）。 现有的（此处称为“ B2C”）车辆保险产品开发以及公共数据库不在本案例研究范围之内。 *Terra*在德国和印度的两个办公地点约有250人。在这250人中大约有150人做产品开发，其他人则是支持功能和“测试工厂”。 另一个部门包括产品管理、业务分析和协调人员（我称其为*PM＆BA＆CO*）。除了市场分析、定价、定义营销活动之外，业务分析部门还负责一些高层次的需求工作，然后将其移交给“协调”部门。 据我了解，该协调部门负责按优先级排序需求，并以发布的形式构建“可销售的特性集”。这些高层次的需求移交给*Terra*。此外，该部门还负责“接受”*Terra*提供的功能、特性和修改。这些活动集中于B2B2C产品。 *PM＆BA＆CO*部门是在LeSS实施的直接范围之外。但是，如稍后的案例研究中所述，这些部门之间的工作方式也发生了一些变化。 *该公司*有很多层级，*PM&BA&CO*和*Terra*之间的共同管理层已经在几个层级之上了（译者注：即*PM&BA&CO*和*Terra*都汇报给同一个更高的管理层）。坦率地说，高层管理人员并不关心*Terra*的组织方式，因此*Terra*内部的管理人员很少得到高层管理人员的支持。 *Terra*自己对B2B产品的客户需求进行分析并确定优先级。该部门的目的是开发这两种产品。 Terra和相关部门的简化示意图 试行阶段 该部门对两个独立的子产品进行了单团队Scrum和工程实践的试验。这些团队由一个PO，一个Scrum Master和一个开发团队组成，每个团队对Scrum进行了大约6个月的试用，并取得了积极的成果。积极的反馈以及其他因素（例如，需要更高的灵活性、对变化的响应能力、业务价值的增加、降低部署的风险、提高产品质量）引领整个部门的敏捷之旅开始了。 该部门建立了一个“敏捷指导联盟”（Agile Guiding Coalition AGC）2，其目的是通过例如定义方向，决定使用哪些框架，帮助团队及消除障碍来指导和支持该部门。AGC由*Terra*的高级管理团队，敏捷教练，架构师，Scrum Master和产品负责人组成。 最初的“Scrum”实施 组织 最初该部门分为以下职能部门： 设计 编码 测试 每个团队都有一个团队负责人（TL3）和一个业务负责人（BL）。最上面是项目经理（PM）。此外，还有一些支持功能，例如架构，版本管理，缺陷管理，运营和其他一些团队。 在最初采用Scrum的开始，我们移除了职能部门并建立了新的结构。 该结构由管理层设计的、十四个分布的Scrum团队（跨职能，但仅限于一个组件）。每个团队都有专门的产品负责人（PO）并且部门有一个整体的首席产品负责人（CPO）4。未改变其他部门（产品，架构等）的结构。 该结构的设计无需任何LeSS专家指导。这项变革是自上而下的一次性5引入的，没有人心甘情愿，也没有得到Terra6部门的高级管理层自上而下的支持。 我开始辅导时，新组建的组件团队是第一次见面。在启动会议上，项目经理解释了变革的原因并传达了方向。 从职能部门到组件团队的结构转变。 在这个阶段AGC决定： 新组建的团队在新架构中工作的日期 2周的Sprint节奏 具有基本的Scrum仪式和（每个Sprint）（产品待办列表）梳理工作坊（PBR）的框架 产品级的Sprint评审，其中志愿团队向其他团队、高级管理层、产品管理人员介绍功能 单独的系统测试功能 Scrum of Scrums 产品负责人创建：
2020/3/1
articleCard.readMore学员感想
来自CSM学员的总结感想，以及来自一线团队的敏捷案例分享。
2020/2/16
articleCard.readMoreSAFe请不要篡改Scrum！
Index | Scrum Master | Product Owner | Dev Team | Scrum SAFe请不要篡改Scrum！ 我们爱Scrum。 我们反对 SAFe（大规模敏捷框架）创建和推广的对于 Scrum 的误解。 当前的SAFe描述明确承诺可以在SAFe中使用Scrum。许多类似的陈述如下： 大多数敏捷团队都将Scrum用作基于团队的主要项目管理框架。 规模化敏捷框架-ScrumXP 此外，当前的SAFe描述使用称为Scrum Master的角色，从而再次直接引用了 Scrum： Scrum定义了敏捷团队中由具有特定职责的两个角色： 产品负责人（PO）和 Scrum Master 。SAFe文章中用该名称进一步描述了每个角色。 规模化敏捷框架-敏捷团队 当前的SAFe描述包含有关Scrum的误导性信息： 1. 如这里所描述的，SAFe中描述的 Scrum Master 角色与其在Scrum中的实际含义存在严重偏差。 2. 如这里所描述的，SAFe中描述的产品负责人角色，与其在Scrum中的实际含义存在严重偏差。 3. 如这里所描述的，SAFe中描述的开发团队角色，与其在Scrum中的实际含义存在严重偏差。 4. 如这里所描述的，根据SAFe当前描述，在SAFe的实施当中不可能采用真正的Scrum。 许多组织相应地实施SAFe，并具有各自的角色和过程。由于当前SAFe描述中的声明，他们可以合理地期望能够在此结构内采用 Scrum。相反，它们受SAFe角色和过程的约束而使用大量 Scrum 反模式并造成严重的功能障碍。 但是，这些组织假定这正是 Scrum 框架，并且他们基于此学习了 Scrum。SAFe引入了对Scrum的完全错误的理解，并剥夺了组织实现其目标的机会。 此外，对于决定在SAFe中发展Scrum Master技能的人来说，这会带来严重的职业伤害。他们学习了错误的理论并采取了功能障碍的行为。之后，他们很难理解真正的差异，以便能够有效地帮助组织正确地采用Scrum。 我们呼吁SAFe的所有者尊重人员和组织，并停止承诺可以在SAFe中使用Scrum和Scrum Master角色！ 因此，以下是在SAFe的描述中需要进行的最低限度修正： 从SAFe描述中删除所有有可能采用Scrum的声明。 在SAFe描述中重命名Scrum Master的角色，以排除其与Scrum有关的实际Scrum Master角色的关联。 * （*）如上所示，SAFe中的产品负责人和开发团队角色与真正的Scrum角色存在严重偏差。但是，只有Scrum Master角色与Scrum不可分割。 为了在该异议下“签名”并在下面显示您的姓名，请访问原文链接。
2020/1/13
articleCard.readMoreScrum - SAFe请不要篡改Scrum！
Index | Scrum Master | Product Owner | Dev Team | Scrum Scrum - SAFe请不要篡改Scrum！ 这里我们将解释，根据SAFe的描述实施的话，不可能采用Scrum的观点。 Scrum是用于开发、交付和维护复杂产品的框架 源自《Scrum指南》 Scrum（名词）：一个框架，人们可以用其解决复杂的适应性问题，同时以富有创造力的方式交付最高价值的产品。 源自《Scrum指南》 Scrum专为产品开发而设计。产品是为客户而生的。整个Scrum团队旨在产生最大的业务价值，始终专注于客户的需求和整个产品。 敏捷团队 – 负责定义、构建、测试以及在适当情况下部署解决方案价值部分的一组人 源自《规模化敏捷框架SAFe - 敏捷团队》 取而代之的是，SAFe描述表明，敏捷团队仅处理部分功能是可以接受的。在现实生活中，这通常会使团队专注于系统组件。 无论如何，每个敏捷团队仅提供功能的一部分，就无法为真正的客户带来任何价值。由于拥有自己的产品待办列表和产品负责人，他们既不关注客户需求也不关注整个产品，而是被迫在系统组件级别上进行本地优化。 如果按照SAFe描述规定，那么甚至还可以所有参与共同产品开发的开发团队都拥有一个产品负责人和一个产品待办列表。这将有机会在Scrum中进行适当的扩展。但是，SAFe的定义给出了完全不同的方案 - 每个敏捷团队都有自己的团队待办事项列表和自己的产品所有者。 根据SAFe当前的描述来实施敏捷，敏捷团队本身不是开发一个产品，所以没有理由去关注客户的需求。取而代之的是，这迫使团队在系统组件级别上进行本地优化。 在下面来自 SAFe 描述的图片中，我们可以看到一个程序板示例，其中显示了不同团队之间的众多功能依赖关系。这不是设计Scrum和规模化Scrum的方式，但这恰恰是完全错误的Scrum方法及其在SAFe中规模化的结果。 框架中的每个组件都有特定的用途，对于Scrum的成功和采用来说至关重要。 源自《Scrum指南》 Scrum是一个框架 - 如果缺少任何元素，对于具有特定上下文的特定公司而言，它可能行不通。但是，在这种情况下，这不是Scrum。 然而，由于如此处所述， SAFe中描述的 Scrum Master 的角色与其在Scrum中的实际含义有严重的偏差。而且，作为如此处所述和[此处所述]((/remove-scrum-from-safe-devteam/)，SAFe中描述的产品所有者和开发团队的角色与Scrum中的实际含义存在重大差异。 这意味着，根据其描述在SAFe中实施的任何内容，都不能与Scrum框架相关联。 本文链接 本文翻译自如下网站，如果译文和原稿有任何差异，请参考原文。 in case of any discrepancies between the translation and the original, the original version should be considered as the correct one Remove References To Scrum From SAFe!
2020/1/13
articleCard.readMoreScrum Master - SAFe请不要篡改Scrum！
Index | Scrum Master | Product Owner | Dev Team | Scrum Scrum Master - SAFe请不要篡改Scrum！ 在这里，我们将解释SAFe描述中引入了Scrum Master角色的观点，但该角色与其在Scrum中的实际含义有重大差异。 如《Scrum指南》中所述，以下内容是Scrum Master的三个重点领域之一： Scrum Master通过多种方式为组织服务，包括： - 领导并指导组织采用Scrum。 - 规划组织内的Scrum实施。 - 帮助员工和利益相关者了解并实施Scrum和经验式产品开发。 - 引领变革以提高Scrum团队的生产力。 - 与其他Scrum Master合作，以提高组织中Scrum应用的有效性。 源自《Scrum指南》 指导组织是Scrum Master的一项重要职责。 相反，在SAFe描述中： - 完全没有Scrum Master负责指导组织（coaching organization）的职责。 - 完全没有Scrum Master负责组织变革（organizational changes）的职责。 据我们所知，文化遵循结构。根据SAFe的描述创建的结构将迫使Scrum Master仅专注于团队，这仅是组织作为系统的一部分。而这通常会导致局部优化，并对整个系统产生负面影响。这是最关键的Scrum反模式之一。 此外，根据《Scrum指南》： 在Scrum指南中定义了，Scrum Master负责推广和支持Scrum。 源自《Scrum指南》 相反，在SAFe中 > 然而，某些团队（尤其是系统团队、运营和维护团队）选择将看板作为主要方法。 源自《规模化敏捷框架-敏捷团队》 尽管 Scrum Master 角色主要基于标准Scrum， 但敏捷团队（甚至是那些应用看板的团队）都可以建立此职位，以帮助团队实现其目标并与其他团队协调活动。 源自《规模化敏捷框架-Scrum Master》 在这些情况下，Scrum Master可以在完全不需要使用Scrum的团队中工作。在这种情况下，Scrum Master无法根据Scrum指南履行上述职责。
2020/1/13
articleCard.readMore产品负责人 - SAFe请不要篡改Scrum！
Index | Scrum Master | Product Owner | Dev Team | Scrum 产品负责人 - SAFe请不要篡改Scrum！ 在这里，我们将解释SAFe描述引入产品负责人角色的观点，该角色与其在Scrum中的真实含义有重大差异。 根据《Scrum指南》中有关产品负责人角色： …整个组织必须尊重他的决定。产品负责人的决定体现在产品待办列表的内容和顺序中。 源自《Scrum指南》 在SAFe描述中，团队待办事项类似于Scrum中的产品待办事项。团队待办列表的工作部分由计划待办列表（Program Backlog）工作填充，而计划待办列表工作是由敏捷团队外部的独立角色 - 产品经理来管理。实际上，在这种设置中，产品负责人并不是团队待办事项列表的唯一决策者。 而且，即使在规模化的情况下，Scrum也会规定： 多个团队经常在同一产品上一起工作。一个产品待办列表用于描述该产品的即将进行的工作。 源自《Scrum指南》 另外，只有一个产品负责人管理共同的产品待办列表，这才是Scrum中合适的规模化的解决方案。 相反在SAFe中，多个敏捷团队以及其各自的产品负责人和团队待办列表的工作是通用的解决方案 - 产品或产品的一部分。在以下视频中，将这种情况清楚地解释为规模化Scrum的主要功能障碍之一。 观看Youtube视频 - https://youtu.be/cr2rjaGmUzo 此外，在SAFe中： PO在质量控制中扮演着重要的角色，是唯一有权接受完成故事的团队成员。 源自《规模化敏捷框架-产品负责人》 这是Scrum反模式。由于以下原因，PO无法承担这些责任： 1. 开发团队有责任确保交付高质量的增量。 2. 在这种情况下，PO控制着开发团队的工作成果，从而像经理一样被定位在更高的位置。它通常会引入合同游戏（contract game），并导致团队功能障碍，破坏团队合作精神。 本文链接 本文翻译自如下网站，如果译文和原稿有任何差异，请参考原文。 in case of any discrepancies between the translation and the original, the original version should be considered as the correct one Remove References To Scrum From SAFe!
2020/1/13
articleCard.readMore开发团队 - SAFe请不要篡改Scrum！
Index | Scrum Master | Product Owner | Dev Team | Scrum 开发团队 - SAFe请不要篡改Scrum！ 在这里，我们将解释SAFe描述中引入开发团队角色的观点，该角色与其在Scrum中的实际含义有重大差异。 根据《Scrum指南》有关开发团队角色： 他们是自组织的。没有人告诉开发团队如何将产品待办事项转变为潜在可发布功能的增量。 源自《Scrum指南》 在SAFe描述中，有专门的系统工程师和解决方案架构师的角色。他们的职责包括： > - 定义子系统及其接口 - 确定主要组件 - 识别接口之间的协作 - 将职责分配给子系统 - 开发、分析、拆分和实现使能（enabler）史诗故事的实施 - 定义、探索和支持赋能者（Enablers）的实施以发展解决方案的意图，直接与敏捷团队合作实施它们 - 规划和开发“架构跑道”（Architectural Runway），以支持新的业务特性与功能 - 定义并沟通共同的技术和架构愿景 - 与解决方案的上下文沟通交流交互的要求 - 使敏捷发布火车（ART）和解决方案火车上的团队保持一致，以实现共同的技术和架构愿景 源自《规模化敏捷框架-系统和解决方案架构师/工程》 如果产品开发需要所有这些，那么这就是Scrum中开发团队职责范围的一部分。但是，在SAFe的描述中，团队以外的其他角色也由开发团队负责。而且，它与开发团队的外部依赖性无关。这与决策有关。 这是一种Scrum反模式，因此开发团队缺乏决策自主权。这通常导致对整体结果缺乏责任感（自主性）。最后，它带来了仅仅对于编码和测试的狭隘关注，并导致缺乏团队合作和实现业务目标的动力。 本文链接 本文翻译自如下网站，如果译文和原稿有任何差异，请参考原文。 in case of any discrepancies between the translation and the original, the original version should be considered as the correct one Remove References To Scrum From SAFe!
2020/1/13
articleCard.readMore社交网络的黑暗心理学
译者注：本文是google机器翻译，阅读原文请翻到最后。 假设圣经中关于创造的故事是真实的：上帝在六天内创造了宇宙，包括所有物理定律和适用于整个宇宙的所有物理常数。现在想象一下，在21世纪初的一天，上帝变得无聊了，只是为了好玩，引力常数翻了一番。经历这样的变化会怎么样？我们都会被拉到地板上；许多建筑物会倒塌；鸟儿会从天上掉下来；地球将靠近太阳，在更热的区域重新建立轨道。 让我们在社会和政治领域而不是物理领域重新进行这种思想实验。美国宪法是智能设计的一项实践。开国元勋们知道，以前的大多数民主国家都是不稳定和短暂的。但是他们是优秀的心理学家，他们竭力创建与人性相适应的机构和程序，以抵抗破坏了许多其他试图进行自治的力量。 例如，詹姆斯·麦迪逊（James Madison）在《第10号联邦主义者》中写道，他担心“派系”的力量，他的意思是强烈的党派关系或团体利益，“激怒了彼此的仇敌”，使他们忘记了共同的利益。他认为，美国的广阔地带可能会为抵御派系主义的破坏提供某种保护，因为任何人都很难在如此大的范围内散布愤怒。麦迪逊认为，有派别或分裂的领导人“可能会在其各自的国家内点燃火焰，但将无法在其他国家之间蔓延开大火。”《宪法》包括了一些机制，可以放慢脚步，让热情降温，并鼓励反思和审议。 。 麦迪逊的设计经证实具有耐用性。但是，如果在21世纪初的某一天出现一种技术，在十年的时间内改变了社会和政治生活的几个基本参数，那么美国民主将会发生什么呢？如果这项技术极大地增加了“相互敌意”的数量和愤怒蔓延的速度，该怎么办？我们可能会目睹在政治上等同于建筑物倒塌，鸟类从天上掉下来，地球越来越靠近太阳吗？ 美国现在可能正在经历这样的时刻。 社交媒体发生了什么变化 Facebook的早期使命是“使世界更加开放和连接” —在社交媒体的头几天，许多人认为，全球连接的巨大增长将对民主有利。但是，随着社交媒体的老化，乐观情绪逐渐减弱，已知或可疑危害的清单也越来越多：在线政治讨论（通常在匿名陌生人中间）比现实生活中的经历更加愤怒和不礼貌；党派人士的网络共同创造了越来越多的世界观；虚假宣传活动蓬勃发展；暴力意识形态引诱新兵。 问题可能不在于连通性本身，而在于社交媒体将如此多的交流转化为公共表演的方式。我们经常将交流视为一条双向路。亲密关系随着合作伙伴的轮流，嘲笑彼此的笑话以及相互交流而建立。但是，如果在那条街道的两边竖立看台，然后到处都是朋友，熟人，对手和陌生人，他们都通过判断并发表评论，会发生什么？ 社会心理学家马克·利里（Mark Leary）创造了“ 社会测度计” 一词，用以描述内在的心理测验，该心理测验时时刻刻告诉我们我们在别人眼中的表现。我们并不真正需要自我 -esteem，猜疑主张 ; 相反，进化的当务之急是使他人将我们视为各种关系的理想伴侣。社交媒体以喜欢，朋友，关注者和转推的形式显示，已将我们的社交量表从我们的私人思想中拉出来，并将其发布给所有人。 人类进化成为八卦，自夸，操纵和排斥的人。我们很容易被这个新的角逐马戏团吸引。 如果您经常在私人对话中表达愤怒，您的朋友可能会觉得您很累，但是当有听众时，回报是不同的-暴怒可以提高您的地位。一个2017年的研究由威廉J.布雷迪和其他研究人员在纽约大学测量五十万鸣叫的范围，发现在推特中使用的每个道德或情感上的字由20％增加了病毒式传播，平均。皮尤研究中心（Pew Research Center）于2017年进行的另一项研究表明，表现出“愤慨分歧”的帖子（包括喜欢和分享）的参与度几乎是 Facebook上其他类型内容的两倍。 哲学家贾斯汀·托西（Justin Tosi）和布兰登·沃姆克（Brandon Warmke）提出了“ 道德显赫”这一有用的用语，用以描述人们在公共论坛上使用道德言语来提高自己的声望时会发生什么。就像一连串演说家对怀疑的观众讲话一样，每个人都在努力超越以前的演说家，从而形成一些共同的模式。正面看台者倾向于“压制道德指控，在公众羞辱的情况下堆积如山，宣布任何不同意道德准则的人显然是错误和夸张的情感表现。”在这场比赛中，细微差别和真相是人员伤亡，以获得观众的认可。旁观者会仔细检查对手（有时甚至是朋友）说出的每句话，以求引起公众的愤慨。上下文崩溃。说话者的意图被忽略。 人类进化成为八卦，自夸，操纵和排斥的人。即使我们知道它会使我们残酷和肤浅，我们也很容易被引诱到这种新的角斗场。正如耶鲁大学心理学家莫莉·克罗基特（Molly Crockett）所论证的那样，当我们看不到这种情况时，可能阻止我们加入暴民的正常力量（例如，反思和冷静的时间或对被羞辱的人的同情心）会减弱。一个人的脸，一天被要求多次，公开表示“喜欢”谴责，以此作为支持。 从2018年10月开始：美国一直生活在詹姆斯·麦迪逊的噩梦中 换句话说，社交媒体将我们许多从事政治活动的公民变成了麦迪逊的噩梦：放纵纵火的人争相创作最具煽动性的帖子和图像，他们可以在全国范围内即时分发这些信息，同时他们的公共社会计量器显示他们的创作有多远旅行。 升级愤怒的机器 成立之初，社交媒体与今天的感觉截然不同。Friendster，Myspace和Facebook都在2002年至2004年间出现，它们提供了可帮助用户与朋友建立联系的工具。这些网站鼓励人们发布精心策划的生活版本，但他们没有办法引发传染性的愤怒。这通过一系列旨在改善用户体验的小步骤得以改变，这些步骤共同改变了新闻和愤怒在美国社会中传播的方式。为了修复社交媒体并减少其对民主的危害，我们必须设法理解这种演变。 Twitter在2006年问世时，它的主要创新就是时间表：用户可以在手机上查看的源源不断的140个字符的更新。时间轴是一种新的信息消费方式，对许多人来说，源源不断的内容就像从消防水带中喝水一样。 那年晚些时候，Facebook推出了自己的版本，称为新闻源。在2009年，它首次添加了“赞”按钮，从而首次为内容的受欢迎程度创建了一个公开指标。然后，它又增加了另一项创新性创新：一种算法，该算法根据预测的“参与度”（确定用户与以前的帖子的相似程度，确定其与给定帖子进行互动的可能性）来确定用户将看到的帖子。这项创新驯服了消防水带，将其变成了精选的流。 News Feed对内容的算法排序使可信度的层次变得平坦。只要生产者参与，任何生产者的任何帖子都可以停留在我们供稿的顶部。“假新闻”稍后将在这种环境中盛行，因为个人博客文章的外观和感觉与《纽约时报》的故事相同。 Twitter在2009年也进行了重要更改，添加了“转推”按钮。在此之前，用户必须将较旧的推文复制并粘贴到其状态更新中，这是一个小障碍，需要几秒钟的思考和关注。Retweet按钮实质上启用了内容的无缝传播。一次单击即可将他人的推文传递给您的所有关注者，并让您分享具有传染性的内容。2012年，Facebook向增长最快的受众：智能手机用户提供了自己的转发版本，即“共享”按钮。 Chris Wetherell是为Twitter创建Retweet按钮的工程师之一。他今年年初向BuzzFeed承认，现在他后悔了。当韦瑟雷尔（Wetherell）看着第一批Twitter暴民使用他的新工具时，他心想：“我们可能刚刚交了一个4岁小孩子的武器。” 政变发生在2012年和2013年，当时Upworthy和其他网站开始利用这一新功能集，开创了在数十种变体中测试标题的艺术，以发现产生最高点击率的版本。这是“您不会相信…”文章及其类似内容的开头，并与经过测试和选择的图像配对以使我们获得冲动的点击。这些文章通常不是要引起暴行（Upworthy的创始人对抬举更感兴趣）。但是该策略的成功确保了标题测试的传播，以及通过新旧媒体进行的情感故事包装；在接下来的几年中，无耻的，道德败坏的头条新闻激增。在Esquire中，卢克·奥尼尔（Luke O’Neil）反思了主流媒体和宣布2013年为“打破互联网的一年”。第二年，俄罗斯的互联网研究机构开始在每个主要的社交媒体平台上动员其假账户网络，利用新的愤怒机器来煽动党派分裂和进步。俄罗斯的目标。 当然，对于今天的政治愤怒，互联网不承担全部责任。自麦迪逊时代以来，媒体一直在煽动分裂，政治学家将当今的愤怒文化的一部分追溯到1980年代和90年代有线电视和谈话广播的兴起。多种力量正推动美国走向更大的分化。但是自2013年以来的几年中，社交媒体已成为任何想要开火的人的有力促进剂。 智慧的衰落 即使社交媒体可以消除其激怒的影响，也仍然会给民主的稳定带来麻烦。这样的问题之一就是当前思想和冲突在多大程度上主导和取代了较旧的思想和过去的教训。随着孩子在美国长大，信息之河不断涌入他们的眼睛和耳朵-各种想法，叙述，歌曲，图像等等。假设我们可以特别捕获和量化三个信息流：新信息（在过去一个月内创建），中年信息（在10到50年前创建，包括孩子的父母和祖父母的后代）和旧信息（创建的信息）。 100多年前）。 现在，人们之间的联系更加紧密，其平台旨在使愤怒蔓延。 无论这些类别的平衡在18世纪是什么，随着广播和电视机在美国家庭中的普及，在20世纪的平衡肯定会转向新的领域。在21世纪，这种转变几乎肯定会变得更加明显，而且很快。当大多数美国人在2012年左右开始定期使用社交媒体时，他们彼此之间建立了超连接，从而极大地增加了对新信息的消费，例如娱乐性，例如猫视频和名人八卦，是的，而且每天或每小时政治动荡和时事热点，同时减少了旧信息的共享。这种转变可能产生什么影响？ 1790年，盎格鲁-爱尔兰哲学家和政治家埃德蒙·伯克（Edmund Burke）写道：“我们害怕让人们以自己的私人理性来生活和交易；因为我们怀疑每个人的存量很小，而且个人会更好地利用国家和年龄的总银行和国家首都。”感谢社交媒体，我们正在着手进行一项全球试验，以检验伯克的恐惧是否成立。社交媒体促使各个年龄段的人都将注意力集中在丑闻，笑话或当今的冲突上，但对于年轻一代而言，其影响可能尤其深远，因为他们在加入社交网络之前很少有机会获得较早的想法和信息-媒体流。 平均而言，我们的文化祖先可能没有我们聪明，但是我们从他们那里继承的思想经历了过滤过程。我们大部分都学到了值得世世代代传承的思想。这并不意味着这些想法总是正确的，但是从长远来看，这比过去一个月中生成的大多数内容更有价值。尽管Z世代（1995年左右出生的人）拥有前所未有的接触所有曾经书写和数字化的内容的经验，但他们可能发现自己不像近代人那样熟悉人类积累的智慧，因此更倾向于拥抱将社交声望带入其直接网络的想法最终被误导了。 例如，一些右翼的社交媒体平台使20世纪最受谴责的意识形态吸引了渴望获得意义和归属感并愿意为纳粹主义提供第二次机会的年轻人。相反，向左倾的年轻人似乎拥护社会主义，甚至在某些情况下甚至怀着热情，有时甚至与20世纪的历史脱节。调查表明，各个政治领域的年轻人都对民主失去了信心。 有回头路吗？ 社交媒体突然改变了无数美国人的生活，并改变了数百万美国人的生活。问题是这些变化是否可能会使麦迪逊和其他创始人在设计自治系统时所做的假设无效。与18世纪乃至20世纪末的美国人相比，现在的公民之间的联系更加紧密，以提高公众绩效和培养道义上的信誉为目的，在旨在使愤怒蔓延的平台上，人们始终将注意力集中在对眼前的冲突和未经检验的想法的思想，与以前发挥稳定作用的传统，知识和价值观没有任何联系。我们认为，这就是为什么许多美国人（以及许多其他国家的公民）将民主作为万事俱备的地方的原因。 [ 在美国的公共生活中，曾经有一段时间，赎罪被视为一种力量，不仅可以弥补自己的失误，而且可以控制叙事。梅根·加伯（Megan Garber）写道，那段时间结束了。 ] 不必一定是这种方式。社交媒体从本质上讲并不是坏事，而是具有做事的力量-就像它揭示了以前隐藏的危害并向以前无能为力的社区发出声音时一样。每一种新的通信技术都会带来一系列的建设性和破坏性影响，随着时间的流逝，人们发现了改善这种平衡的方法。现在，许多研究人员，立法者，慈善基金会和技术行业内部人士正在共同努力，以寻求这种改进。我们建议三种类型的改革可能会有所帮助： 减少公开演出的频率和强度。 如果社交媒体为建立道德风范而不是真正的交流创造动力，那么我们应该寻找减少这些动力的方法。一些平台已经在评估这样一种方法，即“去计量化”，即模糊计数和共享计数的过程，以便可以根据自己的利益评估单个内容，从而使社交媒体用户不受持续公共的对待。人气竞赛。 减少未验证帐户的覆盖面。 不良行为者（巨魔，外国代理人和国内挑衅者）从当前系统中受益最多，在该系统中，任何人都可以创建数百个虚假帐户，并使用它们来操纵数百万人。如果主要平台要求基本身份验证，然后任何人都可以开设帐户，或者至少允许所有者拥有广泛受众的帐户类型，则社交媒体的毒性将立即降低，民主政体的可破解性也将降低。（发布本身可以保持匿名，并且注册的方式必须保护在政府可能惩罚异议的国家/地区中居住的用户的信息。例如，可以与独立的非营利组织合作进行验证。） 减少低质量信息的传染性。 随着摩擦的消除，社交媒体变得更具毒性。已经证明，增加一些摩擦可以提高内容质量。例如，在用户提交评论后，AI可以识别与先前标记为有毒的评论相似的文本，并询问“您确定要发布此评论吗？”这一额外步骤已显示出可帮助Instagram用户重新考虑有害消息。推荐算法传播的信息质量也可以通过使专家组能够对算法进行危害和偏见审核来提高。 许多美国人可能认为，我们时代的混乱是由现任白宫占领者造成的，只要他离开，一切都会恢复正常。但是，如果我们的分析是正确的，那就不会发生。社会生活的太多基本参数已经改变。这些变化的影响到2014年显而易见，而这些变化本身也促进了唐纳德·特朗普的选举。
2020/1/10
articleCard.readMore忘却的教训 -- 保罗 格雷厄姆
您在学校学到的最具破坏性的东西不是您在任何特定班级中学到的东西。它正在学习获得良好的成绩。 当我上大学时，一位特别认真的哲学系学生曾经告诉我，他从不在乎他在课堂上所学的年级，只关心他所学的。这是我想起的，因为那是我唯一一次听到有人说这样的话。 对我来说，对于大多数学生而言，对我所学内容的评估完全控制了大学的实际学习。我很认真；我对参加的大多数课程都非常感兴趣，并且我努力工作。但是，当我为考试而学习时，我的工作是迄今为止最艰苦的。 从理论上讲，测试只是名称的含义：测试您在课堂上学到的东西。从理论上讲，您无需为上课做准备就比为血液检查做准备要多。从理论上讲，您可以通过上课，听讲座，阅读和/或作业来学习，而后来的测试仅能衡量您的学习水平。 在实践中，几乎每个阅读此书的人都会知道，事情是如此不同，以至于听到关于类和测试是如何工作的解释，就好像听到一个词的词源一样，其含义已经完全改变。在实践中，“学习测试”一词几乎是多余的，因为那是一个真正的学习时间。勤奋的学生和懈怠的学生之间的区别在于，前者努力学习测试，而后者则没有。这个学期的两个星期，没有人把通宵的人都拉了。 尽管我是一个勤奋的学生，但我在学校所做的几乎所有工作都是为了在某件事上取得好成绩。 对于许多人来说，前面的句子中有一个“尽管”似乎很奇怪。我不只是讲重言式吗？这不是一个勤奋的学生，一个纯正的学生吗？这就是将学习与年级的融合深深地注入了我们的文化。 如果学习与成绩并列，那么糟糕吗？是的，这很糟糕。直到大学毕业后的几十年，当我运行Y Combinator时，我才意识到情况有多糟。 我当然知道，当我还是一个学生的时候，为考试而学习与实际学习并不完全相同。至少，您不会保留考试前一天晚上塞入脑袋的知识。但是问题比那更糟。真正的问题是，大多数测试都无法接近测量值。 如果测试确实是对学习的测试，那么情况不会太糟。取得良好的成绩和学习将趋于融合，只是晚了一点。问题在于，几乎所有给学生的测试都是骇人听闻的。大多数成绩良好的人都知道这一点，并且对它的了解是如此之深，以至于他们甚至不再质疑它。当您意识到采取其他行动听起来很幼稚时，您会看到。 假设您正在上一门中世纪历史课程，并且期末考试即将举行。期末考试应该考验您对中世纪历史的了解，对吗？因此，如果您现在和考试之间有几天的间隔，那么如果您想在考试中取得好成绩，那么花时间的最佳途径当然是阅读可以找到的有关中世纪历史的最佳书籍。然后，您将对此有所了解，并且在考试中表现出色。 不，不，不，有经验的学生对自己说。如果您仅阅读有关中世纪历史的好书，那么您学到的大多数内容都不会受到考验。这不是您要阅读的好书，而是本堂课的讲义和指定阅读内容。甚至大多数情况您都可以忽略，因为您只需要担心可能会成为测试问题的事情。您正在寻找定义明确的信息块。如果所分配的读数之一在某个微妙的点上有一个有趣的题外话，您可以放心地忽略这一点，因为这不是可以变成测试题的东西。但是，如果教授告诉您1378年分裂的三个根本原因，或“黑死病”的三个主要后果，您最好了解它们。不管它们实际上是原因还是后果，都是无关紧要的。对于本课程而言，它们是。 在大学里，经常有旧考试的副本，这些旧考试的范围更窄，您必须学习什么。除了学习这位教授提出什么样的问题外，您通常还会得到实际的考试问题。许多教授重复使用它们。在教了10年的课后，很难，至少是无意中。 在某些课程中，您的教授将有某种政治斧头需要磨砺，如果是的话，您也必须磨砺它。对此的需求各不相同。在数学，硬科学或工程学课程中，这几乎是没有必要的，但另一方面，有些课程如果没有它，您将无法获得好成绩。 在x班上取得好成绩与从x上学到很多东西不同，您必须选择一个或另一个，并且如果学生选择成绩，就不能怪学生。每个人都根据他们的成绩来评估他们-研究生课程，雇主，奖学金，甚至是他们自己的父母。 我喜欢学习，我真的很喜欢我在大学写的一些论文和程序。但是，在上完某堂课的论文后，我是否曾经坐下来写另一本书只是为了好玩吗？当然不是。我在其他班上要上课。如果涉及学习或成绩选择，我会选择成绩。我没来过大学做不好。 任何关心获得好成绩的人都必须玩这个游戏，否则他们将被超越。在精英大学中，这几乎意味着每个人，因为不关心获得好成绩的人可能一开始就不会出现。结果是，学生竞争以最大程度地提高学习和获得好成绩之间的差异。 为什么测试如此糟糕？更确切地说，为什么它们这么容易被黑客入侵？任何有经验的程序员都可以回答。其作者未曾注意阻止其被黑客入侵的软件的可入侵性如何？通常它像漏勺一样多孔。 可破解性是权威机构进行的任何测试的默认设置。给予您的测试总是如此糟糕的原因-一直以来都无法衡量他们应该衡量的东西-的原因仅仅是因为创建它们的人没有付出太多努力来防止它们被黑客入侵。 但是，如果他们的测试可入侵，您就不能怪老师。他们的工作是教学，而不是创建无法破解的测试。真正的问题是成绩，或更确切地说，成绩已超负荷。如果成绩只是老师告诉学生他们在做对与错的方法的一种方式，例如教练向运动员提供建议，那么学生就不会被诱惑参加考试。但是不幸的是，在一定的年龄之后，成绩已经超出了建议。一定年龄之后，无论何时被教， 我已经以大学考试为例，但实际上它们是最不容易被黑客入侵的。大多数学生一生所经历的所有考试至少都一样糟糕，其中最令人惊奇的是使他们进入大学的考试。如果进入大学仅仅是由招生人员以科学家衡量物体质量的方式来衡量其心智的问题，那么我们可以告诉十几岁的孩子“学到很多东西”，然后就去做。作为测试，您可以从听起来与高中的不同中看出大学录取的糟糕程度。在实践中，有抱负的孩子在高中必须做的事情异常特殊，这与大学录取的可入侵性成正比。您不关心的课程主要是记忆，即随机的“课外活动” 除了对孩子的行为不利之外，从很容易被黑客攻击的角度来看，此测试也很糟糕。如此容易破解，整个行业都已成长为黑客。这是应试公司和招生咨询师的明确目的，但这也是私立学校职能的重要组成部分。 为什么这个特定的测试如此容易被黑客入侵？我认为是因为它正在测量。尽管通俗的故事是，进入一所好大学的方法真的很聪明，但精英大学的招生人员既不是也不自以为是。他们在找什么？他们正在寻找的不仅是聪明的人，而且在某种程度上更值得称赞的人。以及如何衡量这种更一般的赞赏？招生人员感觉到了。换一种说法， 因此，大学入学考试是对您是否适合某些人的口味的考验。好吧，这样的测试当然是可以入侵的。而且由于它很容易被黑客入侵，并且（应该）有很多风险，因此被黑客入侵就没有别的了。这就是为什么它会这么长时间扭曲您的生活。 难怪高中生经常感到疏远。他们的生活完全是人为的。 但是浪费时间不是教育系统对您造成的最坏的事情。它做的最糟糕的事情是训练您，成功的方法是通过破解错误的测试。这是一个非常微妙的问题，直到我看到其他人都遇到后才意识到。 当我开始为Y Combinator的创业创始人提供咨询服务时，尤其是年轻的创业者，我为他们似乎总是使事情变得过于复杂而感到困惑。他们会问，您如何筹集资金？使风险资本家想对您进行投资的诀窍是什么？我会解释，使风险投资家想要对您进行投资的最好方法是实际上是一项良好的投资。即使您可以诱骗风险投资人投资一家糟糕的初创公司，您也会欺骗自己。您要在要求他们投资的同一家公司中投入时间。如果这不是一项好的投资，您为什么还要这样做呢？ 哦，他们会说，然后停下来消化一下这个启示后，他们会问：是什么让初创公司成为一笔不错的投资？ 因此，我要解释的是，使初创企业充满希望的，不仅在投资者眼中，而且实际上是 增长。理想的收入来源，但使用失败。他们需要做的是吸引大量用户。 如何获得大量用户？他们对此有各种各样的想法。他们需要进行一次大规模的发布，才能使他们“暴露”。他们需要有影响力的人谈论他们。他们甚至知道他们需要在周二发布，因为那是人们获得最多关注的时候。 不，我要解释，这不是如何吸引大量用户的方法。吸引大量用户的方法就是使产品真正出色。这样，人们不仅会使用它，还会将其推荐给他们的朋友，因此，一旦开始使用，您的成长将成倍增长 。 在这一点上，我已经告诉创始人，您认为有些事情是完全显而易见的：他们应该通过制造优质的产品来打造优质的公司。然而，他们的反应就像许多物理学家第一次听说相对论时所必须做出的反应：表面上天才的惊讶混合在一起，再加上怀疑任何奇怪的事情都不可能是对的。好吧，他们会忠实地说。您能向我们介绍如此有影响力的人吗？记住，我们要在星期二发布。 创始人有时有时需要几年才能掌握这些简单的教训。并不是因为他们懒惰或愚蠢。他们似乎对眼前的事物视而不见。 我为什么要问自己，为什么它们总是使事情变得如此复杂？然后有一天我意识到这不是一个反问。 当答案正确摆在他们面前时，创始人为什么会束手无策呢？因为那是他们被训练做的事。他们的教育告诉他们，获胜的方法就是破解测试。而且甚至没有告诉他们他们正在接受培训以做到这一点。年轻的应届毕业生从未经历过非人为的考验。他们认为这就是世界运作的方式：面对任何挑战时，您所做的第一件事就是弄清楚破解测试的诀窍。这就是为什么对话总是从如何筹集资金开始的原因，因为这被视为一种考验。它是在YC的结尾。它附有数字，数字越大似乎越好。它必须是测试。 当然，在世界上很多地方，获胜的方法就是破解测试。这种现象不仅限于学校。有些人由于意识形态或无知而声称这对初创公司也是如此。但事实并非如此。实际上，关于初创公司最引人注目的事情之一就是您只要做好工作就能赢得胜利。有很多情况，但总的来说，您可以通过吸引用户来赢得胜利，而用户所关心的是该产品是否满足他们的要求。 为什么花了我这么长时间才能理解创始人为何使初创企业变得过于复杂？因为我还没有明确意识到学校训练我们通过破解不良测试来取胜。不只是他们，还有我！我也曾接受过恶意测试的培训，直到几十年后才意识到这一点。 我过着好像意识到的生活，但是不知道为什么。例如，我避免在大公司工作。但是，如果您问为什么，我会说那是因为他们是虚假的或官僚的。或者只是。我不了解我对大公司的厌恶有多少是由于您通过破解不良测试而获胜。 同样，测试是不可破解的，这吸引了我很多初创公司。但是我还是没有明确地意识到这一点。 实际上，我已经通过逐次逼近实现了可能具有封闭形式的解决方案。在不知道自己正在做的事情的情况下，我逐渐放弃了对黑客进行恶意测试的培训。某个放学了的人能不知道这个恶魔的名字，然后说“要死”就驱除这个恶魔吗？似乎值得尝试。 仅仅明确地谈论这种现象可能会使情况变得更好，因为它的力量很大一部分来自于我们将其视为理所当然的事实。在您注意到它之后，似乎是房间里的大象，但这是一只伪装得很好的大象。这种现象是如此古老，并且无处不在。这仅仅是疏忽的结果。没有人会这样说。当您将学习与年级，竞争和天真的不可破解性假设相结合时，就会发生这种情况。 令人惊讶的是，我最困惑的两件事-高中的虚假性和让创始人看到明显事物的难度-两者都有相同的原因。这么大的块难到这么晚才滑入位。 通常，发生这种情况时，它会在许多不同的领域产生影响，这种情况似乎也不例外。例如，它建议可以更好地进行教育，以及如何解决它。但这也暗示了所有大公司似乎都存在的问题的潜在答案：我们如何才能更像一家初创公司？我现在不打算讨论所有的含义。我想在这里重点介绍的是对个人的意义。 首先，这意味着大多数有野心的孩子从大学毕业后都会有一些他们想学的东西。但这也改变了您对世界的看法。现在，您可以提出一个非常具体的问题，以一种有趣的方式对他们进行分类：您会在多大程度上赢得这种工作，而不是看人们所做的所有不同类型的工作，或多或少地将它们模糊地视为有吸引力。通过破解不良测试来工作？ 如果有一种方法可以快速识别不良测试，则将有所帮助。这里有模式吗？原来有。 测试可以分为两种：一种是由权威机构强加的，另一种不是。权威人士未强制进行的测试本质上是无法入侵的，从某种意义上讲，没有人声称他们对测试的测试超出了实际测试的范围。例如，一场足球比赛只是对谁获胜的考验，而不是哪个球队更好。从评论员有时之后说更好的团队获胜的事实可以看出这一点。权威机构进行的测试通常是其他事情的代理。课堂测试不仅要衡量您在特定测试中的表现，而且还要衡量您在课堂上学到了多少。虽然不是由权威机构强加的测试本质上是不可入侵的，但必须将权威机构强加的测试设为不可入侵。通常他们不是。因此，作为第一近似， 您实际上可能想通过破解不良测试来取胜。大概有人这样做。但是我敢打赌，大多数发现自己从事这种工作的人都不喜欢它。他们只是理所当然地认为这就是世界的运作方式，除非您想退出并成为某种嬉皮工匠。 我怀疑许多人暗中认为在一个测试不佳的领域工作是赚钱的代价。但是，我可以告诉你，这是错误的。曾经是真的。在二十世纪中叶，经济 由寡头垄断组成，进入榜首的唯一途径就是玩他们的游戏。但这不是事实。现在有通过做好工作来致富的方法，这就是人们对致富比以往更加兴奋的部分原因。当我还是个孩子的时候，你要么成为一名工程师，做些很酷的事情，要么成为一名“执行官”，从而赚很多钱。现在，您可以通过制作有趣的东西来赚很多钱。 随着工作与权威之间的联系逐渐消失，破解不良测试变得越来越不重要。这种联系的侵蚀是目前正在发生的最重要的趋势之一，我们看到它在人们所做的几乎每一种工作中都会产生影响。创业公司是最明显的例子之一，但是我们在写作中看到的几乎是同一回事。作家不再需要向出版商和编辑屈服以接触读者。 我对这个问题的思考越多，我就会越乐观。这似乎是其中一种情况，在这种情况被消除之前，我们不知道有多少东西会阻碍我们前进。而且我可以预见整个虚假的建筑物在崩溃。想象一下，随着越来越多的人开始问自己是否想通过破解不良测试来取胜，并决定不这样做，会发生什么。通过骇人听闻的测试而获胜的工作将因人才而饿死，而通过做好工作而获胜的工作将涌现出最有野心的人。而且，随着恶意测试的重要性越来越小，教育将逐渐发展，以停止培训我们去做。想象一下，如果发生这种情况，世界将会是什么样。 这不仅是个人学习的一课，还是社会学习的一课，当我们这样做时，我们会为释放的能量感到惊讶。 原文链接
2020/1/9
articleCard.readMoreCertified ScrumMaster CSM年薪调查2019
CSM Certified ScrumMaster 2019年薪水调查 先上图，看2019年CSM薪水调查结果 Salary.com PayScale.com ziprecruiter.com 总结 什么是CSM 如何成为CSM
2019/12/28
articleCard.readMore如何用google cloud存储分区搭建网站 个人博客
Step 1 注册 google cloud - https://cloud.google.com/?hl=zh-cn 1.1 所在地随意选择，我选择新加坡，填写正确的信用卡，选择个人 激活后获得一年的免费使用（300美元或365天，先用完就结束免费期） Step 2 准备验证域名 3.1 自己有域名，如我的域名是 bobjiang.com 3.2 验证你是否拥有该域名，打开 search console 3.3 点开左上角下拉的小三角，选择添加资源 3.4 网域（domain）输入自己的跟域名，如 bobjiang.com ， 点击继续 3.5 到域名注册商的管理页面（我用的 godaddy.com），找到自己域名的DNS管理 3.6 增加一条DNS解析记录， 类型 TXT，值复制页面上 google提供的内容 3.7 点击验证，如果验证不通过需要多等一下，最多等1天 Step 3 准备域名指向 4.1 到域名注册商的管理页面（我用的 godaddy.com），找到自己域名的DNS管理 4.2 增加一条DNS解析记录， 类型 CNAME，值 www， 指向 c.storage.googleapis.com. Step 4 创建google存储分区 5.1 进入项目选择器页面 5.2 选择一个你拥有的域名，如上述我的 bobjiang.com 5.3 创建新的存储分区，名字是 www.bobjiang.com （一定是这个名字!!! 和你的CNAME一致） Step 5 上传文件并修改权限 6.1 用控制台上传文件，如打开 cloud storage 浏览器 6.
2019/12/27
articleCard.readMore美国空军国防部企业级DevSecOps启动会探讨
本文是针对于最近网上流传的美国空军国防部企业级DevSecOps启动会上，对于敏捷的疑问展开讨论。 欢迎共同来探讨。 The CSO signed a Memorandum for Record on Nov 26th 2019, sent to all PEOs and PMs regarding the use of DevSecOps and Agile and highly discouraging from using rigid, prescriptive frameworks such as the Scaled Agile Framework (SAFe). CSO（Chief Software Officer）首席软件官于2019年11月26日签署了一份备忘录，该备忘录已发送给所有PEO和PM，涉及使用DevSecOps和Agile以及强烈不鼓励使用诸如Scaled Agile Framework（SAFe）之类的严格定义的框架。 为什么？以下是CSO对于上述结论的理由： DoD is still using Waterfall or Water-Agile-Fall so until we can truly implement basic Scrum/Kanban, there is nothing to « SCALE ».
2019/12/12
articleCard.readMore敏捷词汇表
English Version 敏捷词汇表 A Acceptance Criteria (AC)接收标准（验收标准） 产品负责人从业务或干系人角度定义的外部质量特征。接收标准定义期望的行为并用于判定PBI（产品待办列表条目）是否开发完成。 为了让用户、客户或其他权威机构认可，组件或系统必须满足的退出标准 Acceptance Test 接收测试 验证是否满足接收标准的测试过程。 一种测试，定义每个PBI必须交付的业务价值。接收测试可以验证功能需求或非功能需求，如性能或稳定性。这种测试用来帮助指导开发过程。 针对用户需求和业务流程的正式测试过程，执行此过程以确定系统是否满足接收标准，并且使用户、客户或其他授权的实体能够决定是否接受此系统。 Acceptance Test Driven Development (ATDD) 接收测试驱动开发 一种技术，在开发过程开始之前，参与者使用实例讨论接收标准，然后将其分解成一组具体的接收测试。与“实例化需求(Specification By Example)”同义。 Accountability 责任担当 教练信任教练对象，并通过双方从开始就共同设计的架构和方法，以不带主观臆断和责备的态度，使教练对象在思考、学习或行动的过程中对自己的发展进程和目标负责。教练以“每个人都要对自己的发展b负责”的心态来协助教练对象建立起对自己的责任担当系统。建立责任担当的问题包括：“你会怎么做？”“什么时候？” Adaptation 适应（调整） 经验式过程（Empirical Process）的三个支柱之一；适应是一种反馈，用来对正在开发的产品或产品开发过程进行调整。另外可以参阅“经验式过程”、“检视”和“透明”。 Agile 敏捷 敏捷宣言中表示的一组特定的加个管和原则。参见敏捷宣言网站。 泛指，用于指代一组相关的增量式迭代开发方法。Scrum是一种敏捷开发方法。另请参阅“极限编程”、“看板”和Scrum。 Artifact 工件 在产品开发过程中产生的实际附属物。如产品待办列表、冲刺待办列表和潜在可交付的产品增量都是Scrum的工件。 B Boy Scout rule 童子军原则 离开营地时，总是做到比发现时更干净。如果地上脏乱，不管是谁弄脏的，都清理干净。 每次在一块代码区工作，离开时总是要把代码整理得比你动手时更干净，而不是弄得更乱。 burndown chart 燃尽图 一种曲线图，横轴是时间（如迭代内的每天），纵轴上是迭代内剩余工作量。随着时间的推移，剩余的工作量越来越少，图表上的一般趋势是工作量燃烧到0.通过计算趋势线，可以在燃尽图上显示对应的产出，从而了解工作什么时候可以完成。如下图： burnup chart 燃烧图 和燃尽图相对。一种曲线图，用来显示逼近目标的工作进度，纵轴上标有目标值。随着时间推移，工作逐渐完成，进度线条逐步上升并接近于目标线。在燃烧图上，我们可以通过计算趋势线显示对应的产出，从而了解什么时候可能完成。如下图： C cadence 节奏 规则的、可预测的节律或心跳。具有一致持续时间的冲刺，为每一次开发工作建立节奏感。 chaotic domain 混乱域 需要快速响应的一种情况。我们深陷危机，需要立即采取行动，以防止损失扩大化并至少需要重新建立一定的秩序。 Cynefin框架中域的一种。请参阅“繁杂”、“复杂”、“简单”域。 commitment 承诺 把自己和行动过程绑定在一起的行为。Scrum鼓励承诺。承诺意味着无论顺利与否，每个团队成员都专注于达成团队的共同目标。
2019/12/9
articleCard.readMoreAgile FAQs
We are looking for the translators please contact bob@bobjiang.com 中文版 Glossary Agile
2019/12/5
articleCard.readMoreAgile Glossaries
中文版 Source Glossary A Acceptance Test Driven Development (ATDD) Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality. (see more) Acceptance Testing An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
2019/12/5
articleCard.readMore敏捷问题集
English Version 我要提问 我要回答 加入敏捷社区，限时优惠 目录 [TOC] 问题1 如果Scrum团队中有一个团队成员不愿意认领该Sprint中的任何任务，作为ScrumMaster你会怎么办？ 问题2 如果Scrum Master同时兼任团队成员，认领任务，你认为可以吗？如果可以，为什么？如果不可以，为什么？ 问题3 下午2点马上要开Sprint计划会议，现在是下午1点50分。产品负责人说他没时间参加Sprint计划会，但他不介意在他缺席的情况下团队自己开Sprint计划会。作为Scrum Master你会怎么办？ 问题4 你是团队的ScrumMaster，准备去会议室开会。此时团队的分析师边哭边从你身边跑过，另一位工程师也怒气冲冲的从你身边跑过，他们都跑向经理的座位。你走进会议室，明显感觉到会议室的气氛不对，剑拔弩张。平时分析师负责编写需求并传递给工程师，分析师总是修改需求，埋怨逐步积累并在这次爆发了。在这个时候，作为Scrum Master，你会怎么做？ 问题5 如果一个项目需要大量的架构工作，比如需要6周时间来进行基础架构设计，那么是否可以前3个Sprint（假设一个Sprint是2周）用来做架构设计呢？如果可以，原因是什么？如果不可以，原因是什么？ 问题6 Scrum Master能不能同时兼任多个团队的Scrum Master？如果可以，原因是什么。如果不可以，原因是什么。 问题7 Sprint进行到一半的时候（比如两周的Sprint，过去了一周），总监要把团队中的一名骨干成员调走到另一个重要的项目。作为Scrum Master，碰到这样的情况，你会怎么办？请列出具体的解决方案以及原因。 问题8 你听说公司内有个团队在用Scrum并且很成功，如果你也想在自己的团队尝试Scrum，你会怎么做？ 问题9 每日站会上，团队成员A不关心其他人的内容（和其他人的任务没有交集），也不认为有必要关心。作为Scrum Master，你会怎么办？ 问题10 连续3个Sprint团队都只完成了承诺的Product Backlog Item的一部分（即没有完成计划会上的承诺），作为Scrum Master，出现这个情况，你会怎么办？ 问题11 假设这是团队的第一次Sprint评审会（Review），客户（或业务方）说他很忙，没有时间参加Review会议。作为团队的Scrum Master，这种情况下你会怎么办？ 问题12 敏捷宣言中提到“可工作的软件”高于“详尽的文档”，快速响应变化，那么假设你是一个测试人员，如何在一个scrum团队中快速把握每个需求间的内在联系，更好的覆盖测试对象？ 问题13 今天的题目和每日站会有关。假设你是团队的ScrumMaster，在开每日站会的过程中（比如进行到一半的时候），有一名团队成员突然离开（他已经回答完三个问题了）并回到座位上开始他的工作，如果出现这样的情况，作为ScrumMaster，你会怎么办？ 问题14 在每日站会上，团队成员A说他完成了任务1，今天计划完成任务2.团队成员B说等一下我有个问题，任务1和我手上的任务3需要做联调测试，任务3我还没完成，任务1不能算完成。为什么会出现这种情况？如果出现这种情况，作为ScrumMaster，你会怎么办？ 问题15 假设你是团队的ScrumMaster，你们团队马上要开始一个新项目（公司的重要项目）。整个团队都很兴奋，但是对于团队能够完成多少工作以及什么时候完成，团队搞不清楚如何给管理层一个大致的估算。此时，作为ScrumMaster，你会怎么办？ 问题16 你正在参加一个大型的项目开发，产品列表（product backlog）里面大概有200多个条目（需求）。假设你是产品负责人，项目刚刚启动，你需要对着200多个条目进行排序，这个时候你会怎么办？ 问题17 实行敏捷之后，工作量很透明，也拆分了任务，大家也都认领。但有一个问题：怎么能让大家认领工作更合理，有些人3天做一个任务，有些人一天做3个任务。如果光靠任务量来统计，也不公平，因为能力不同，任务难度不同。所以，问题是作为ScrumMaster，怎样能更合理的分配工作？ 问题18 新来的成员不愿意在早会上吐露心声，总会觉得早会是秀的场合。如果不说出点高大上的就不好意思说，也不维护看板，也很被动。你也找他单独谈过几次，但也没有改变。作为ScrumMaster，你还会怎么办？ 问题19 一个Sprint中团队提前3天完成了所有的需求，作为ScrumMaster你会怎么办？如果提前了0.5天完成了所有需求呢，你会怎么办？ 赞助 有了你的赞助，Bob会继续更新本页面，以及敏捷词汇表 以太赞助：0x521aacB43d89E1b8FFD64d9eF76B0a1074dEdaF8
2019/12/5
articleCard.readMore即兴表演体验
11月24日，星期天，北京的天气晴朗但北风嗖嗖，温度已经到了零下5度。 顶着5级大风，乘着欢快的地铁，我按时赶到了位于白石桥的新世纪日航大酒店。 今天我有一个话题（工作坊），便签公司。即如何用便签来体验规模化敏捷。 如果想要了解更多关于工作坊，可以扫下面的二维码。 今年敏捷之旅最大的收获是参加了开放空间中的一场即兴表演 即兴表演中，我积极参与其中，乐得其所。 整体1个小时的时间中，娜娜同学（引导者）表现的相当出色，成功地带着这群IT人疯了起来。 热身是几个小游戏，热身的重点在于身体要动。 体验 no; yes, but; yes, and 对眼神移位 热身后，主要有2个大环节： A.阿尔法星球人 三个人一组，手挽手 每个人每次只能说一个字，即相当于三个人扮演一个人来说话 假定一个场景 然后由场下观众进行提问，注意尽量提开放式问题 反思：接龙的时候，尽可能按照常规逻辑接，比如上个人说今，下个人紧接着说天，不需要过多思考。 停顿时间越长，大家的思绪就越容易跟不上。 如果一句话结束了，下一个人要主动停，尽量不要去开启意料之外的话题。 B.即兴表演 4-5人一组 2个人上前进行表演 注意，尽可能动作到位（或夸张） 剩下的2-3人随时喊 停 然后上前拍台上2人中的1人肩膀 替换台上的人 用刚才的动作，继续另一个场景环节的表演 反思：这个环节，我的内心有一些紧张，不是很容易入戏。 或许放下自我，只要接上一个动作即可。 这两个环节由浅入深，由易到难。整体设计很棒。 再次感谢娜娜，以及未来会Show，大家可以搜索微信公众号关注哦。 总结：即兴表演和敏捷思想有相通之处： 先热身，暖场 从简单到困难，逐步掌握 先动手，再思考 Yes, and 最后感谢敏捷之旅北京的组织者廉雨和张明同学。（只有廉雨的照片啦） 以及更多其他的志愿者们 - 最后送上一张大合影 - 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 版权声明 本文采用 CC BY-NC-SA 3.
2019/11/24
articleCard.readMore敏捷认证大全
今年年初，我曾经写过一篇敏捷认证对比的博客。后来有博友咨询是否有更新，今天特地抽出时间整理了一下最新情况。 本文尽量客观的描述每个敏捷认证（及机构），如有不正确的地方，麻烦留言指出。 全文一共分为三大部分： 1. 敏捷认证大全 2. 敏捷认证的对比（更新版） 3. 如何选择敏捷认证 敏捷认证大全 目前市面上已经有的敏捷发证机构如下： - Scrum联盟成立于2001年，全球超过100万会员。 - Scrum.org成立于2009年。 - PMI-ACP，ACP认证创建于2011年。 - EXIN，敏捷认证创建于2016年。 - LeSS成立于2014年。 - SAFe成立于2011年。 - Scrum@Scale成立于2018年。 敏捷认证对比 Scrum联盟 机构介绍 Scrum联盟成立于2001年，是敏捷行业最早、影响力最大的机构之一。更多Scrum联盟介绍 认证体系介绍 Scrum联盟的认证体系非常完整，按照Scrum中的三个角色划分：Scrum Master、产品负责人和开发团队。 Certified Scrum Master (CSM) –> Advanced CSM –> CSP-SM Certified Scrum Product Owner (CSPO) –> Advanced CSPO –> CSP-PO Certified Scrum Developer (CSD) –> 待定 –> CSP 除了以上三个角色的认证，还有更进一步的晋级，即导师级认证。分别为： - Certified Scrum Trainer (CST) - Certified Enterprise Coach (CEC) - Certified Team Coach (CTC)
2019/11/20
articleCard.readMore比较百分比和大多数
作者：赛斯高丁（Seth Goddin） 评论与问题： > 精准人群比大众人群，更加可靠。 直接营销人员并不关心他们触达的人数。 他们关心的是采取行动的百分比。 品牌营销人员在度量行动方面存在困难， 因此他们所需要做的就是触达目标。 如果你可以度量，在触达时不要再担心大数了。 远离超级碗或主要公路上的广告牌。 小型受众群体是您的朋友，因为小型受众群体是特定的，并且具体会提高转化的百分比。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/25
articleCard.readMore三个愿望
作者：赛斯高丁（Seth Goddin） 评论与问题： > 假设未来，以终为始。写下未来的三件事情（具体化），来探索当前的项目。 如果您对项目感到困惑，请抓起三张卡片。 在每张卡片上写下项目的一个元素，比如投入更多的时间和金钱，就会变得更好。 如果这三件事发生了，或这三个元素得到改善，你的项目会发生什么？ 好的，假设你已经拥有了这三个元素……你打算怎么办呢？ 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/24
articleCard.readMore媒体接下来会带我们去往哪里
作者：赛斯高丁（Seth Goddin） 评论与问题： > 媒体，下一步是什么方向。或许小圈子、社交媒体（比如部落）会更加有效。 自第一个故事被刻在岩石上以来，媒体权威人士已经解释说，他们只是简单地向人们提供了他们想要的东西，并在发生的事情上报告最好的情况。 有因（文化、人类活动、人们的欲望）必有果（头版新闻）。 事实上越来越清楚的是，引人注目的、以利润为导向的媒体工业综合体推动我们的文化甚至超过报道。 有思想的人经常哀叹我们文明的丧失，拖钓和欺凌的崛起，最重要的是，分裂的行为旨在将人们分开，而不是让我们富有成效地前进。 与此同时，真人秀电视获得了更好的收视率。 因此，新闻已成为历史上运行时间最长，成本最低，腐蚀性最强的电视节目。 通过添加社交媒体的点对点真人秀节目，以指数方式增加，您可以看到正在发生的事情。 想象一下两个教室，每个教室都装满了二年级学生。 在第一个教室里，老师对欺凌者，麻烦制造者和战士们的关注度很高，甚至安排所有的椅子，以便学生们整天看着他们并为他们加油。 在第二个教室，老师建立标准，充当自私异常值的阻碍者，并在课堂上庆祝慷慨和富有成效的孩子…… 教室将如何分歧？你宁愿让你的孩子报名参加哪一个？ 我们不再上小学了，媒体不是我们的老师或我们的保姆。 但是，我们对点击的电子频道的关注比我们在二年级时与宾德小姐一起度过的消耗更多。 这种关注具有腐蚀性。 对我们和我们周围的人。 真人秀的制片人知道这一点。 他们寻求更多的东西。 当他们无法轻易找到它们时，他们会更加努力。 因为那是他们的工作。 他们的工作就是提升我们文化的真人秀节目。 但是买入它并不是我们的工作。 最重要的是，利润驱动的媒体需要我们积极参与才能支付账单。 这是一场不对称的比赛，大量的行为研究对我们每个人都起作用。 也许我们可以找到寻求、连接和组织其他人实际运作方向的决心。 第一步是停止诱饵。 第二步是说“跟我来”。 译者注：站出来，领导一场变革！ 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/23
articleCard.readMore两种系统的风险
作者：赛斯高丁（Seth Goddin） 评论与问题： > 人类对于可靠性的乐观程度，对比对于失败可能性的悲观程度。所以结论是大部分人喜欢成功，厌恶失败。 设置系统时，如果不起作用，请记住会发生什么。根据“不工作”的成本，您可以在系统中建立更强的弹性。 在大多数情况下，“不工作”并非灾难性的。如果你的烤面包机不起作用，那就没什么大不了的了。你可以在几天内做吐司，同时和跛行的面包一起生活。另一方面，如果你正在执行火星任务，你可能会很高兴你装了一些额外的氧气罐，即使它们带来的成本非常高。 我们在组织系统时犯了两个错误： 1. 我们对系统的可靠性过于乐观，并将其与叙述相结合，最大限度地降低了没有它的生活成本。我把互联网基础设施的当前状态放在这类中。 2. 我们对失败的可能性和成本过于悲观。这导致我们过度设计工作，或者为我们应该支付更多的冗余。把救生衣放在飞机上就是一个很好的例子。避免上一个错字也是如此。这也是我们的医疗成本如此之高的一个原因……最后的 .01％ 是最昂贵的部分。 行政决策的一项有用技能，能够以非情感方式描述弹性和失败成本。特别是在很难做到的时候。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/22
articleCard.readMore跟随
作者：赛斯高丁（Seth Goddin） 评论与问题： > 跟随，经常是国内公司的一种策略。研究竞争对手是需要的，但一直跟随并不会让你成为第一，且不可能超越对手。 跟随不会让你走得更快。 跟随也并没有让领导者走得更快。 跟随会造成挫败感，限制你的选择并且不安全。 如果你想要有所作为，你可能需要找到自己的车道。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/21
articleCard.readMore前进还是逃跑
作者：赛斯高丁（Seth Goddin） 评论与问题： > 广告都可以写的令人深思，这个讨论可以学习一下。另外多次的排比句，也是Seth同学常用的套路。 现在你站在你老板的办公室外，希望她能和你见面谈你的新项目呢？还是你在办公位里蹲下，希望老板不注意你？ 你会在课堂上举手，希望得到一些讲话时间，还是你会坐在后面避开讨论？ 你会追踪一个顽固的顾客，看看你是否能把事情变得更好，或者你是否会在他们试图追踪你的情况下躲过语音邮件？ 你可以花一整天的时间来寻找你想要的东西。或者，您可以花时间逃跑。 这是代表altMBA的道路上的分叉。明天是10月我们经过验证的工作坊的第一个优先截止日期，这是学费增加之前的最后一次工作坊。 如果您已准备好开始行动，我们随时准备提供帮助。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/20
articleCard.readMore说出你想要什么
作者：赛斯高丁（Seth Goddin） 评论与问题： > 走着走着就忘记了初心，时刻记得初心是个重要的事情。 委婉语比以往更加容易。广泛的笔触，雄伟的语言，伟大的想法……使命宣言和人道主义动机。 值得注意的是，有组织的体育运动是第一个出现超自然现象的地方之一，对于今天的比赛来说仍然是诚实的。 “我们的目标是得分高于他们。” 很清楚团队正在尝试做什么。 通常，我们忙着谈论我们的理想和动机，以至于忘记让我们的同事准确地知道我们想要做什么。 “我们的目标是确保州参议院对该法案投反对票。” “我们希望本月能再卖出10,000多个套餐。” “实际上，我们所有的股东都在关注的是提高季度销售额。” 仅关注短期的问题在于它会导致人们偷工减料，产生负面结果并在变革面前崩溃。 我们的首要任务很重要。 但对自己诚实也很重要。 如果您的团队经常以伪装的紧急情况暂停您所声明的总体任务，以寻找您并不感到自豪的结果，那么现在是时候承认紧急情况就是您实际所做的事情。 这是一个简单的测试：如果竞争对手出现的人能够比你更快更有效地完成你所宣称的任务，你会为他们加油吗？ 如果你不为自己的实际行为感到自豪，也许你可以去探索其他事情。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/20
articleCard.readMore每小时50000美元的登机口代理人
作者：赛斯高丁（Seth Goddin） 评论与问题： > 对于公司而言，你的韦德在哪里？很多公司都在努力提升员工敬业度，但敬业度可以通过培训提高吗？对于提高敬业度你有什么好方法？欢迎留言分享。 传统的首席执行官的观点是，高层管理人员因为他们做出的高杠杆决策而值得发财。 但考虑一下韦德的工作，这是一位没有人注意到的加拿大航空公司登机口代理人。 昨天，我看到他为雇主赚取至少5万美元，而他的薪水可能是0.1％。 麦克风发生了故障，但他不是向乘客尖叫，而是直接向需要听他讲话的人说话。 他自己开始询问一个四口之家的转机状况。他本可以清理等待名单，关闭航班并告诉四人他们必须找到回家的路。 或者，他本可以将他们的四个座位保存起来，如果他们没有被填满，那么这些座位就会空着。 他没有采取任何一个措施，而是拿起电话，组织其他工作人员帮助这家人的生活及登机。 然后，在一个无关紧要的勇气中，他找到了一个丢失的钱包， 并在飞机起飞前将钱包从遗忘的地方送到了2号登机口。 最重要的是，在忠诚度稀缺的时代，他可能会将十几个摇摆不定的客户的终身价值提高至少几千美元。 克鲁克法则规定，一个组织的未来掌握在该领域的私人手中，而不是在国内的将军手中。 不幸的是，管理和缺乏信任会妨碍你需要建立的工作环境，以获得下一个韦德的人性化专注工作。希望这家航空公司接下来会让他负责他们可怕的网站。但我并不乐观。 你的韦德在哪里？ 你做了什么让他或她明天更有可能带来魔力？ 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/19
articleCard.readMore吱吱作响的轮子
作者：赛斯高丁（Seth Goddin） 评论与问题： > 抱怨还是行动，取决于选择。如果发现了问题并行动起来，这就是创业者心态了。你身边有什么问题需要去解决的吗，你行动了吗？ 你真的想要油脂吗？ 或者你宁愿把事情做得更好？ 为社区或品牌做出贡献的最佳方式不是抱怨。 这是通过改善事物来实现的。 承担责任（没有权威）并创造一个积极的慷慨行动循环。 以身作则。 寻找一个可以发挥作用的小角落 - 然后有所作为。 我们不断优化我们的系统以避免吱吱作响的车轮。 但通常，我们得到的只是一个补丁，而不是修复。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/18
articleCard.readMore这是哪种演示？
作者：赛斯高丁（Seth Goddin） 评论与问题： > 不同类型的演讲，采取的方法不一样。是操作指南类型，还是改变思想类型呢？ 如果您要进行演示（而不是发送备忘录）…… 如果您打算打电话（而不是呆在家里）…… 这是因为你想要做出改变。你在寻求什么行动？ 您可以使用如下两种改变： 已经有一个目标和一系列承诺，这里有关于如何采取适当行动来实现这一目标的更新。 示例：汽车中的GPS。它知道你想去克利夫兰。它会向您提供有关到达目的地的最新信息，或者有关您的旅程的前方交通警报。请注意，GPS并没有问你为什么要去克利夫兰，也不想让你去其他地方。 主持人想要改变优先级，想要不同的东西。 例子：我知道你以前从未给过像这样的慈善机构捐款，但是一旦你看到正在发生的事情的紧迫性，它就会改变你的想法。 如果您正在进行GPS更新，那么您的演示文稿应该专注于沟通我们知道需要采取行动的事实和改变。 另一方面，如果你正在做一个关于改变人们思想的演讲，请告诉我们不相关的坐标并轮流发布公告。你来改变，请求它。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/17
articleCard.readMore付费学习
作者：赛斯高丁（Seth Goddin） 评论与问题： > 付费跟高手学习，绝对是最划算的投资。你最近一笔付费学习是什么课？ 传统教育的基本原理是，更多的学习可以让你获得更好的工作，而工作可以让你获得报酬，这使得学习成为一项有价值的投资。 但是你得到那份工作后会发生什么？ 在一些组织中，这就是结束。 你可能会在工作中获得经验和智慧，但短视的组织可能会认为持续学习过于昂贵。 洞察力是要意识到停滞的员工比受过教育的员工要贵得多。 越来越多的组织开始明白，支付员工学习，真正挖掘和学习的东西，是一种便宜货。 一个富有灵感且富有洞察力的员工将比那些被忽视的员工产生更多的价值。 员工开始明白，他们在继续教育中投入的时间和精力会在他们的职业生涯中回归到他们身边，因为一旦你学会了它，你可以一次又一次地使用它。 我们整理了一份公司名单的核心，这些公司积极报销其员工的教育。 更好的决策，情感劳动和来自教育的信心是工作的未来。无论你是在那条路上，还是在落后。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/16
articleCard.readMore你被什么所吸引？
作者：赛斯高丁（Seth Goddin） 评论： > 吸引飞蛾的事物很简单，吸引我们的事物是什么。现在物质极大丰富，每个人的选择很多。如何抓住吸引力，是个很难的问题。 所有飞蛾都是一样的。 对于正确的物种，如果点燃蜡烛，飞蛾就会出现。他们被吸引到它的原因很少，因为他们的联系方式很少。 正如飞蛾似乎是一样的，人类也会变得与众不同。 你如何度过计划外的时间？ 什么会分散你的注意力或提升你的优先级列表？ 也许你被危险所吸引。 也许你被冲突所吸引。 也许你被享乐主义的乐趣所吸引。 也许你会被采取行动避免批评吸引。 也许你被闪亮的物体或新的机会吸引。 也许你被从无休止的待办事项清单中解决问题吸引。 可能是你无法抗拒在其他人的工作中修正错字，或者你宁愿在团队运动中获胜而不是任何其他事情。 也许你想做一些安全的事情。 有些人想做的事情实际上是安全的。 对许多人来说，要么是避免麻烦，要么是赞美的欲望，但很少同时出现。 可能最重要的是修复看似破坏的东西。 或者它可能是为了避免看起来破碎的东西，而是跑到新的，未被玷污的机会。 在离开家之前，您可能需要关掉所有的灯并准备好床。 你可能愿意交易所有东西只是为了确保整个世界不会想到你在工作中踌躇满志的那一刻。 我们的紧迫性种类繁多，很明显我们不是飞蛾。 机会在于理解我们所吸引的是否真正帮助我们实现了我们所寻求的结果。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/15
articleCard.readMore根据天气判断一天
作者：赛斯高丁（Seth Goddin） 评论与问题： > 掌控自己的生活和命运，而不是怨天尤人。用天气来判断，类似于怨天尤人。昨天的成绩是完成了2天全新的CSPO课程，与CSM的重合度低于10%。 通过一些相关的，有用的和可控制的东西判断明天，而不是下雨，不是更有效吗？ 我们可以根据我们使用工具的数量，有多少人愿意听取我们的意见，有多少问题可以解决，来判断一天。 天气或任何其他不受我们短期控制的事情都可能成为借口，和使我们分心。 如果你无法做任何事情，可能不值得你专注和投入精力。 我们可以首先接受这样一个事实： 我们需要一整天才能产生影响。 我们可以打开大门，寻找新资源，创造价值。 尽管这是普遍的条件…… 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/15
articleCard.readMore现在有了食谱....
作者：赛斯高丁（Seth Goddin） 评论： > 偶尔看一些有趣的事情，会增加生活乐趣。美食是永恒的话题。 问题：最近你有经历哪些有趣的事情？ 在过去的几个月里，我在这个博客的页面上添加了一些食谱，主要是因为我把它们放在手边，部分是因为我没有在网上找到类似的东西。 如果您想了解办公室的官方午餐食品，请点击此处： 每日达尔（这是我所知道的完美食物。素食，简单，充实和美味。你可以在一个满是人的办公室里服务。一次购买香料，你就可以吃几个月了。）我们在下面的铸铁披萨盘上制作dosa。 几乎生生蛋糕。它们非常令人难以置信，几乎和By the Way的那些一样好。 此外，一页厨房用品可以完全改变你的烹饪方式……玩得开心。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/14
articleCard.readMore原则和正在摆脱困境
作者：赛斯高丁（Seth Goddin） 评论： > 原则与坚持原则，看似很简单的事情。但在某些极限情况下，是否能坚持原则才最重要，最难能可贵。 问题：你的原则是什么，什么时候你会打破原则？可以的话，请举例说明~ 我们在困难时期暂停的原则并非真正的原则。当它们难以维护时，原则确实很重要。 然而，这不是同一件事，因为拒绝考虑边缘情况。 “言论自由”是一个很好的原则，一个可以生活的原则。但有充分理由不允许在拥挤的电影院里大喊“着火啦”。 边缘案件总是受到无休止的争论。没有简单的亮线。因此，从不考虑边缘情况是很诱人的。 规则就是规则。 但是没有判断力的原则并不是他们看似简单的道路。 因为没有我们对边缘案件的判断，我们已经放弃了责任。 如果我们不作出决定，我们的决定就不再是我们的决定。 努力工作包含自愿陷入困难的召唤。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/13
articleCard.readMore竞争就在身边
作者：赛斯高丁（Seth Goddin） 评论： > 投身于竞争中，还是寻找一块蓝海（无人竞争的业务）？ 问题：真的存在无竞争的业务吗，你可以列举一下，谢谢。 在渔人码头（Fisherman’s Wharf），有一家又一家餐馆。就在所有其他业务旁边开展业务，这是明智之选吗？ 在书店里有成千上万的书，每本书都在争相找一个读者。 问题是，当周围没有很多书时，书籍是不可能售出的。他们不会在梅西百货（综合百货）卖出很多书。 大多数市场营销人员面临的最大竞争对手是“无”。没有竞争总是占据最大的市场份额。 令人惊讶的解决方案是被竞争所包围。因为这将问题从“if？”变为“which？” 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/12
articleCard.readMore人人都在某处划条线
作者：赛斯高丁（Seth Goddin） 评论： > 有人划的线条长，有人划的短，有人划的粗，有人划的细。每个人划出来的都不一样。这代表了这个世界的多样性。 问题：你身边的同事（或同学）为什么会做那些（愚蠢的）事情呢？ 人们当然会这样做。 有趣的见解是要意识到我们划的线似乎每次都在正确的位置。 习惯于我们的线条是独一无二的， 这是了解如何与看待不同事物的人交往的第一步。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/7/11
articleCard.readMore打开括号
作者：赛斯高丁（Seth Goddin） 评论： > 有始有终，一件事情、一个潮流、开始了就会有结束。要学会观察结束的标志。从下面可以看出，如果大众可以很容易获取的，就代表括号要关闭。 问题：敏捷将要关闭了吗？ 打开括号 技术出现并改变了文化。 然后，文化使新的产业和运动成为可能，进一步改变了文化。 然后技术出现并结束了我们习以为常的系统。 括号打开，然后，它们可能会关闭。 流行摇滚的括号用晶体管收音机打开（孩子们可以在没有他们父母的情况下听音乐）并关闭流媒体（没有稀缺意味着长尾意味着没有大众市场）。 出版的括号以古腾堡开头，随着书店的去世而告终。数字图书意味着没有稀缺的货架空间，没有稀缺的纸张，没有发行商的权力，没有大众市场。 一扇门打开，然后，有一天，它关闭。 很容易哀悼这些时代的结束，但在我的一生中，这么多的括号已经打开…… 计算机将我们与资源，真理和彼此联系起来（这可能意味着民间真理而不是真实的事实） 医学确实是一门科学，而不是一系列半懂的迷信 音乐家和作家可以在没有看门人的情况下找到观众 我们改变了关于公平的叙述（即使我们刚刚开始取得进步） 传播创意或创办企业从未如此简单 几乎所有信息的访问都是便宜而快速的 如果你足够关心学习什么，你可以 这可能是一天交易悲剧和厄运，如果这是让事情变得更好的最佳方式，我会赞成它。 但是，随着所有已经打开的大门，有什么机会让事情变得更好。做一些事情，让事情变得更好。 HT Kevin Kelly，Chris Anderson，Bernadette Jiwa， Jeff Jarvis，Rohan Rajiv，Paul McGowan，Dan Pink，Roz Zander，David Deutsch等等。更多关于本周播客的系统思考。 开始一个项目。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.
2019/7/10
articleCard.readMore你用的是正确的文化模式吗
你用的是正确的文化模式吗 作者 | Michael K Sahota 译者 | 陈旭，BoB 授权出品 | 敏捷变革中心 阅读原文 以下为译文： 敏捷的首要挑战是文化-多年来行业研究一直表明，适应新的工作方式通常不会与“日常工作”融为一体。若想敏捷取得成功，我们需要了解其文化以及如何正确的贯彻。关键问题是：你是否使用了正确的文化模式？或者换个不那么挑衅的问法：你使用的文化模式有多有效？让我们分析一些常用的模式，看看它们相较如何。 施耐德文化模式？不。 早在2011/2012年，我就开始尝试施耐德文化模式，以了解和改变组织文化。我的工作和我的博客文章（如何让你的文化有效[注1]）对敏捷社区产生了巨大的影响。（只需看看有多少人使用了这张图，或者引用了我的图表中的单词和符号）。 这个模式我比较喜欢的是： - 容易理解 - 它不评判文化系统，因此可以更加安全地谈论正在发生的事情 - 它可以在一个研讨会中被介绍并激发关于文化实际上是什么的广泛讨论 我停止使用它的原因是： - 它在任何一个给定的文化体系中都是适用的，即使其实际上在不同文化体系上的表现存在着非常明显的差异 - 要明确改变文化是很有挑战性的 竞争价值观框架？不。 在一个非常高的层次上，人们可以理解这或多或少与施耐德模式相同，并且具有相似的特性。我的同事皮特·贝伦斯很好地解释了竞争价值框架相比与施耐德模式的优势[注2]。其优点之一是，它将领导行为与文化象限联系起来。 作者Cameron&Quinn在“诊断和改变组织文化：基于竞争价值框架”中分享了一个非常有力的见解： “表现最好的领导者在四个象限中的每一个象限中都培养了能力和技能。” 高绩效来自于对这些文化象限的超越和整合。这意味着高绩效文化没有一个单一的定义，它是一个超越性性的属性，融合了所有文化。当然，有一个模型提供了一条更清晰的道路。 拉卢文化模式？对！ 这种模式来自于对组织的重塑，这是组织发展中的一本里程碑式的书，它能释放人们的才能，取得惊人的成果。它是螺旋动力学（Spiral Dynamics）的简化和修订版本。这本书是以世界各地组织的案例研究为基础的，这些组织以一种新的工作方式取得了成功。我简化了这个模式，将其变体展示在上面的图表中，并且对teal有一个更相关的定义。（请阅读此处了解拉卢文化模式的解释[注3]。） 当我们分析研究结果和数据时，可以非常清楚地观察到所有文化系统实际上并不相同。但事实上，他们都有一种明确的关联：随着信任和认知（或观念）的逐步加深，组织成果和大家的参与度也会随之增加。 拉卢模型非常强大 - 它非常清楚地向领导者展示他们所负责的组织系统并不是很高效。它要求领导者在听取意见时必须有足够的同理心和理解能力来获取真实的心声。但是当他们确实在倾听时，这就会是一种极大的激励。 它为什么这么好用？一个是它基于真实的公司研究。另一个更重要的点是，每个人在看完模型后都想要“Go Teal”。它激发了人们对保持增长而持续投资的渴望。它帮助领导者意识到他们的红/橙文化实际上是低绩效的。相比之下，人们可以在离开施耐德或竞争价值模型的情形下依旧感觉他们做得很好。 注意：我并不是在鼓吹所有人都要“Go Teal” - 这是一个陷阱。有关此问题的进一步见解和指导，请参阅：如何改变您的组织文化[注4]。 Sahota文化模式？是 事实证明，仅使用拉卢文化模型并不足以应对组织文化的复杂性。提供动力和渴望也是很必要的，然而，有效的改变需要更深入地理解文化本身的概念。 Sahota文化模型[注5]通过识别塑造文化的内联元素提供对文化的清晰理解。它还强调了不仅要关注结构，还需要关注系统意识（或心态）。我们经常陷入只关注结构（特别是过程），而不是人们本身以及他们如何在一起工作的陷阱。这个模型提醒我们，它实际上是关于意识（或心态）和人，而不是关于结构或过程。 延伸阅读 我写了很多关于组织文化变革的文章。下面两篇博文可以作为您探索我博客的起点： - 如何改变您的组织文化[注4] - 如何在各种文化背景下成功敏捷[注6] 原文链接 如何让你的文化有效[注1] 竞争价值框架相比与施耐德模式的优势[注2] 拉卢文化模式的解释[注3] 如何改变您的组织文化[注4] Sahota文化模型[注5] 如何在各种文化背景下成功敏捷[注6] 行动 每日问题 你的组织文化是如何识别的，用了什么模型？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表
2019/6/21
articleCard.readMore给产品负责人的十条扩展建议
作者: Roman Pichler 原文: https://www.romanpichler.com/blog/10-scaling-tips-for-product-people/?doing_wp_cron=1561070340.3916580677032470703125 给产品负责人的十条扩展建议 管理不断增长的产品是一件荣耀与挑战并存的事情：让更多人和团队参与并扩大规模并非易事。本文分享了10个实用技巧，以帮助您（产品负责人）进行有效地扩展。 1. 让合适的人参与进来 少数拥有合适的技能和主观能动性的个人要比那些不专业的当一天和尚撞一天钟的人更具生产力。根据我的经验，产品人员和开发团队成员都是如此。因此，努力让合适的人参与进来。这样可以让您的团队更长时间的保持灵活与高效，并且更具适应性。 虽然这可能听起来像常识，但我看到不止一个组织试图通过随意的增加人手到产品中来完成更多工作。例如，我与之合作的一家公司指派了使用古老编程语言开发企业信息系统的开发人员去开发采用最新技术的全新嵌入式产品。毫无疑问这些人在新岗位上非常挣扎，产品也蒙受了损失。 您的Scrum Master应该能够帮助您找到合适的人并清除相关障碍 - 例如，在没有考虑他们的技能和动机的情况下进行人员调动。 2. 不要过早扩张 我曾经参与过一项新产品开发工作，从项目开始就在三个地点分配了100多名开发人员。虽然最初没有足够的工作让这么多人忙碌，但是开发团队不想浪费时间，开始编写软件。这导致了一个膨胀的、过于复杂的代码库和一个难以适应且维护成本昂贵的产品的诞生。 与其过早地扩大规模，不如尽可能地保持小规模，直到接近产品产生市场价值的规模。这允许您快速响应市场反馈，试验新想法，并进行任何可能需要的架构和技术变动，以便进入增长阶段。 3. 建立最小可行性 另一种减少规模扩张需求的好方法是推出一款最小可行性的产品。与功能更丰富、更有抱负的产品相比，开发这样的产品通常需要更少的时间和更少的人员。更重要的是，它可以更容易地适应市场的变化，以实现产品与市场的契合。 你的产品能有多小取决于它的市场。例如，在最初的iPhone上，苹果创造了一个新的市场，因此可以提供一个相对简约的产品。与之形成对比的是，Apple Watch进入了一个现有市场，直接与三星(Samsung)、Garmin和Fitbit等公司的成熟产品竞争。 4. 帮助开发团队实现自给自足 随着产品的增长，工作负载通常也会增加: 处理越来越多的需要花费更多的精力来理解的不同的用户需求，并决定如何最佳地处理这些需求。如果您的开发团队在这个阶段仍然需要填鸭式地提供详细的需求，那么您的工作量可能会变得非常巨大。 为了减少这种风险，帮助开发团队尽早了解用户并了解他们的需求，例如，让团队成员参与用户调研(作为产品发现工作的一部分)，并让他们直接获得用户对早期产品增量的反馈。这将允许团队成员对解决方案拥有自主权，并做出正确的技术决策，提高参与积极性，为添加更多的团队打下基础，并使您不必创建细节丰富的用户故事并在sprint期间回答许多问题。 5. 有机增长 早在1968年，Melvin Conway就观察到“一个系统的结构和设计它的组织结构之间有着非常密切的关系。”这意味着，如果您从三个开发团队开始，那么您产品的软件体系结构可能由三个主要的子系统组成——不管这个体系结构是否支持所需的用户体验和特性。 为了避免这种风险，从一个产品负责人、一个开发团队和一个Scrum Master开始。一旦您验证了关键的用户体验和技术风险，就可以通过要求团队拆分来进行扩展。然后在新组建的团队中加入更多的人。这种方法也被称为有机生长，因为它模仿了生物的细胞分裂。 除了避免上面提到的Conway法则,有机增长还提供了两个额外的好处:它使增加人手的效果落到实处而不是让一个低效的团队处理所有的新特性,它允许您测量增加人手在生产力和基础设施上的影响。 后者可能看起来相当枯燥，但我曾经与一个组织合作过，为了加快开发速度，该组织一口气从3个开发团队提升到了8个。不幸的是，没有人预料到基础设施无法处理新团队造成的网络流量增加。因此，签入和签出代码突然需要花费几分钟而不是几秒钟，这意味着开发速度显著降低，直到升级工作完成后情况才有所好转。 6. 雇佣功能所有者和功能团队 随着您在开发工作中添加更多人员，请考虑使用功能团队 - 实现端到端功能的团队- 而不是像前端或持久层一样按架构分块构建组件的团队。与组件团队相比，功能团队具有更少的团队间依赖性，并降低了局部优化的风险，提高了整体产品性能。但是，它们确实需要统一标准以避免定义不良变量和代码重复：您通常不希望每个功能团队都重新开发自己的UI而放弃已有的可用代码。 当您将功能团队引入到开发工作中时 - 希望是通过有机增长的方式- 您还必须考虑对工作负载的影响。我的经验表明，单个产品人员通常无法与三个以上的敏捷开发团队合作。因此，您必须考虑让其他产品人员参负责该功能并指导功能团队，我称这些人为功能所有者。下图显示了如何应用该角色。有关更多信息，请参阅我的文章“扩展产品负责人角色”。 7. 从一个站点开始，以循序渐进的方式分发工作（如有必要） 虽然很难将合适的人员聚集在一起，但软件开发中有一些事情比分散团队 - 团队成员在不同地方工作 - 例如伦敦，波士顿和班加罗尔开展新产品开发工作更具反作用。 一般来说，存在越多的不确定性，变化和创新就会越多，参与开发工作的每个人都在同一地点办公（包括产品负责人）就越重要。这使您可以培养融洽的团队氛围，建立有效的协作并就共享标准达成一致，例如，如何协作优化产品待办事项以及进行有效的冲刺评审。 因此，在一个站点的一个团队开始新产品的开发工作。一旦解决了关键的用户体验问题和技术风险，如果需要，可以考虑以循序渐进的方式将工作分散到其他站点。这使您可以了解如何通过布局分布式团队来改进您的实践以取得成功，包括通过视频会议进行产品策略审核和产品待办事项优化的协作。 8. 考虑分拆功能和创建产品变体 成长是一件有趣的事情。虽然这是一个值得庆祝的理由 - 产品终于进入了成长阶段并取得了成功 -我们现在必须应对日益庞大且复杂的目标群体，更多样化的需求，更多的功能以及更多的开发团队。但它不一定非得这样。 还记得Facebook在2014年拆分Messenger并将其作为独立应用推出吗？分拆是一项很好的技术，可以避免成功的产品变得越来越大，越来越异构，并且需要越来越多的人来管理和开发它。取而代之的是，您可以使用自己的专业产品人员和开发团队创建新的专业产品。 产品变体执行类似的工作：但是，您可以创建针对一组特定的目标规划版本，而不是分离一个或多个功能。以微软的图表工具Visio为例，该公司提供VisioStandard和Visio Professional等变体。每个变体都可以由一个单独的团队开发，并拥有自己的产品人员来负责。 9. 利用平台优势 平台会捆绑一些共享资产，例如，共享的前端或后端组件或常见服务（如持久层，日志记录和安全防护），并标准化它们的使用方式。使用平台在扩展环境时有两个好处：首先，它鼓励重用并避免每个团队重复造轮子，比如日志服务。其次，它创建并实施跨不同功能和团队的标准，例如通用用户界面设计。 在创建平台时，您有两种选择：集体所有，要求不同的功能团队共同管理和改进平台。或者，您可以通过专门的平台所有者和团队管理平台。（请注意，平台所有者通常需要深厚的技术功底，因为他们通常需要功能团队讨论新接口和现有接口的更改。）
2019/6/21
articleCard.readMore假敏捷Fake Agile
假敏捷 Fake Agile 作者：Steve Denning (from Forbes) 译者：乔梁 （微信公众号：持续交付2.0） 我现在的微信签名是“别提概念，只解决问题”。而在2013年之前，我用的签名是“别提敏捷，只解决问题”。 为什么呢？因为在2012年的腾讯，敏捷开发方法似乎早已成为“过去时”。但是，还有一大堆问题要解决呀。 （上图与腾讯无关，来自我朋友圈的@王宇） 今天的文章是Martin Folwer在“推它”上一个引用，原文发表于福布斯网站，作者是Steve Denning。点击文末的”原文链接“，看英文版。 正文如下： 有个公司请我去讲讲“假敏捷（fake agile）”。他们想讲我解释一下，如何识别假敏捷，以及如何处理这种情况。这个要求是可以理解的。 就像穿着弗拉门戈服装和谈论弗拉门戈的人一样，没有掌握弗拉门戈舞步或展示弗拉门戈音乐的感觉或天赋，一些所谓敏捷管理的例子的确与真正的敏捷是相关的，但又似是而非。 随着人们越来越认识到“敏捷正在吞噬世界”。德勤和麦肯锡的调查显示，超过90％的高级管理人员高度重视敏捷，而不到10％的人认为他们的公司目前非常敏捷。 愿望与现实之间的差距导致大量的经理，顾问和教练声称自己敏捷并提供帮助公司变得敏捷。 不少公司也有首席执行官问：“我们为什么不敏捷？” 因此，“敏捷”一词经常被抛出，而并未对其含义达成任何共识。 它通常适用于对任何敏捷性没有实质性要求的公司或公司的一部分。 在某种程度上，事实上，实际上非常敏捷的公司往往回避标签，“敏捷”，并使用他们自己的本土词汇，感觉更真实。 1、定义“敏捷” 为了解决困惑，我们需要对真实事物进行定义。 正如这里所解释的，我对过去十年的研究表明，敏捷的主要成果是体现了具有三个主要组成部分的思维模式的公司。 为了强调所有这三个组成部分的重要性，我只是半开玩笑地称它们为“法律”。也就是说，除非你遵守所有这些“法律”，否则你无法真正称你的组织是“敏捷的” 。 我在这里谈论的是整个公司的敏捷性或业务敏捷性。因为，经验表明，只有整个公司使用相同的步调运行时，才会产生敏捷的主要成果。 2、敏捷三定律 客户法则 - 专注于为客户提供价值，作为组织的全部和最终目标。 小团队法则 - 假设所有工作都由小型自组织团队进行，工作周期短，专注于为客户提供价值 网络法则 - 持续努力消除官僚主义和自上而下的等级制度，使公司作为一个互动的团队网络来运作，所有这些都集中在共同努力，为客户提供越来越多的价值。 该定义包括运营敏捷性（operational agility，使现有业务更好）和战略敏捷性（strategic agility ，生成新产品和服务，从而引入新客户）。 该定义独立于那些术语、标签，或者是特定的专有流程或特定品牌。 3、没有标签的敏捷 该定义认识到，一些最成功的敏捷最终都在企业内部实现了本土术语。 换句话说，这些公司甚至没有称自己敏捷并且回避标准的敏捷词汇，其中一些（如Scrum）被故意设计为对管理层没有吸引力。 亚马逊，苹果，Facebook，谷歌，Netflix和微软等大多数规模最大，发展最快的公司在其所做的大部分工作中都具有敏捷性，即使他们通常不使用标准的敏捷词汇。 他们的业务敏捷性是他们成为世界上最有价值公司的重要原因。 3、敏捷的初级阶段 敏捷是一段旅程。 没有哪个公司能够在第一天实施敏捷的所有元素。 掌握敏捷的各个方面需要时间。 当一家公司处于敏捷旅程的初期阶段时，人们可能会称之为“早期敏捷”。这不是假的敏捷，而是“它是不完整的”。 如果旅程顺利进行，那么公司将逐步掌握所有三项敏捷法则以及战略敏捷性。 旅程永无止境：公司继续寻找变得更加敏捷的新方法。 公司敏捷旅程的路径顺序可能不同。 例如，微软大约十年前开始使用小型敏捷团队，如下图所示。 它继续在2008 - 2014年期间以稳步增长的规模进行试验。 只有在Satya Nadella成为微软首席执行官的这段时间之后，这种方法才开始传播到整个组织，人们可能会认为微软是一家开始体现业务敏捷性的公司。 人们可能会称，2014年之前的微软是一个”敏捷初级阶段“公司。 相比之下，亚马逊从1997年股票市场首次亮相开始就接受了对客户的痴迷，明确承诺致力于为客户创造价值并实现市场主导地位。 仅仅五年之后 （大约2002年），亚马逊就拥抱了“双披萨团队”，并开始将网络连接在一起，而不是自上而下的层级。 在此之前，将亚马逊称为早期敏捷实例是合适的，尽管其旅程中早期步骤的顺序与微软不同。
2019/6/20
articleCard.readMore黑暗敏捷 Dark Scrum
黑暗敏捷 Dark Scrum 作者：Ron Jeffries 译者：陈旭 （微信公众号：敏捷变革中心） 我们来谈谈“黑暗Scrum”。至少在软件方面，Scrum似乎常常压迫人们。通常，Scrum不能像它本该的那样快速、可靠、稳定地交付。结果，每个人都在受苦。大多数情况下，开发人员比任何人都要承受更多的痛苦。 我最近很多想法背后的主题是： 我最初的“敏捷”导师Kent Beck曾经说过，他发明极限编程是为了让程序员的世界更加安全。事实证明，这个世界对程序员来说还并不安全。Scrum可能对程序员来说是非常不安全的。用Scrum的联合创始人之一Ken Schwaber的话来说:“这让我很难过”。 我很认真的说Scrum其实做得相当好，也是一个很好的框架。与决定需要做什么和需要推迟做什么的业务人员有紧密的联系是件好事。团队拥有构建产品所需的所有技能是件好事。每隔几周就构建一个经过测试的有形产品是件好事，向涉众（stakholders）展示它也是件好事，回顾工作的进展以及如何改进它们也是件好事。多年来，我一直在研究、实践和思考Scrum，关于它的一切都非常好。不是很完美，但真的很好。 不幸的是，这只是Scrum的理念，一个理想的按照预期的方式进行的Scrum。就像每一个好的理念一样，现实有时也不尽人意，有时它远远不及设想。我称之为“黑暗Scrum”。 黑暗Scrum: Scrum的一些典型滥用 让我们看看在黑暗Scrum中，事情是如何出错的，只需几个步骤。在本节中，我们将观察一个经历黑暗Scrum的团队，黑暗Scrum领导者的本意是好的，他们只是做错了。 自组织是缓慢发生的 显然，要精通Scrum需要一些时间。它有新的角色和活动。更困难的是，它要求我们接受新的价值观。我们应该让我们的开发人员自行组织工作。我们很容易组织Scrum会议，并通过Scrum角色来称呼自己。但真正做起来却并不容易。 Scrum开始时，接受过培训的人很少，理解它的人更少。很多人认为他们知道自己应该做什么，不过如果他们做错了也不奇怪，事实上他们经常做错。 当今的掌权者常常认为他们的工作是决定人们应该做什么，告诉他们去做，并监督他们做。Scrum则不然，Srum解释需要做什么，然后退后一步，让员工自行组织去完成它。 以Scrum模式运营并不容易。忘记旧的习惯需要时间，学习新习惯需要时间，学习信任团队也需要时间，团队也需要时间来学习如何被信任，在某种程度上，这就是本文想要传递的潜在信息。Scrum的培训为接受培训的人开启了这个学习过程。 黑暗Scrum始于那些熟悉自己的旧工作，但不熟悉新工作的人进行Scrum活动的时候。它是这样的: 太棒了，我们每天都可以帮助团队 每天，团队会聚在一起组织一天的工作。这种做法，即“每日Scrum”，典型的Scrum团队都会做。房间里可能有一个人，ScrumMaster，他被告知应该怎么做。程序员没有被告知，很多时候，甚至产品负责人也没有被告知。几乎可以肯定，其他掌权者也还没有被告知。 但掌权者已经知道他的工作。他的工作是高高在上的监督每个人都在做的事情，确保他们正在做正确的事情，否则就让他们改正。每天都有强制性的会议让他可以这么做，这是多么方便！ 结果是：团队无法围绕他们的任务群策群力，整理出一份适宜的当天的工作方案。取而代之的是掌权者将信息从他们身上抽离出来，在自己的头脑中处理，然后再告诉每个人该做什么。由于事情没有像昨天早上预期的那样被完成，这种不正当的活动往往气氛紧张并充满了互相责备。 黑暗Scrum每天都会压迫团队，自组织不可能产生。 我们也有快捷频繁的规划！ 每个Sprint，Scrum产品负责人都应该与团队会面，并描述需要什么。然后团队确定他们可以做些什么来满足需求，并开始构建它。嗯，理论上就该这样。可实际上，甚至可能没有业务方面的产品负责人。即使有，他们可能也没有接受如何成为产品负责人的培训。 好吧，掌权者有者可能是Scrum的新手，但他们对如何处理这个问题知之甚多。因此，每两周他们就会出现并告诉这些程序员他们必须构建什么。哦，那些程序员会反击。他们懒惰，顽固。但掌权者会继续施压，因为这就是他管理人的方式。所以他们告诉团队该做什么，他们最好这样做。 当然，掌权者很少或根本不知道如何编程，程序员通常至少有一些线索。他们不知道代码的状态是什么，程序员通常都知道。程序员应该决定某项任务在Scrum中的工作量，但在黑暗Scrum中，掌权者更懂这个。他们把任务堆积起来分配，他们认为这是他们的工作：驱使团队前进。 结果永远不会改变。团队认真地尝试做被要求做的事情。他们知道无法说不可能，尽管它就是不可能的。他们只是会因为懒惰，愚蠢和制造麻烦而受到谴责，所以他们尽力而为，但就是不够好。 在Sprint结束时，结果不符合要求。魔法再一次没有发生，开发人员再次失败了。幸运的是，我们有机会直接处理这些事：Sprint评审！ 我们需要批判性的评审已完成和未完成的事项 每个Sprint，利益相关者都会了解团队已达成的成果，并提供接下来相关工作的指导。伟大的理论，但在组织没有精通Scrum的情况下很少能在实践中完成。 黑暗Sprint回顾的第一步是提醒每个人团队“承诺”做什么。（也就是说，在团队说“我们会尝试”之前就提出要求。这是一个承诺，不是吗？）然后看看团队带来的可怜的失败。 你猜怎么着。组织要的比能完成的多，并且没得到满足。团队尝试了，并且在尝试时他们采取了他们能想到的所有捷径来完成所有那些不合理的请求。他们压缩测试工时，他们压缩设计工时，他们甚至在太累而无法思考时工作。 他们没有足量完成工作，已完成的工作做的也并不是很好。团队再一次失败了。 幸运的是，黑暗Scrum拥有掌权者，产品所有者和利益相关者，他们确保程序员可以完全了解他们做得多么糟糕。这肯定会激励每个人下次做得更好，在这一点上，我们有Sprint回顾！ 我们要告诉他们该如何改进 在Sprint回顾中，团队回顾上一次Sprint，以及之前的历史。他们观察哪些进展顺利，哪些进展不顺利，并弄清楚如何在下一次进行改善。 在实践中，黑暗Scrum掌权者会帮助他们，提醒团队尽管他们被紧紧的管理着，但仍存在不足之处。掌权者向这些开发人员明确说明他们的失败- 这种失败 - 肯定是由于他们的懒惰和无能导致的。 为了激励团队做得更好，掌权者会不停的摇头叹息并指出不改进的后果，这总是会引起团队的注意。 有时团队会提出建议。以下是他们可能会说的一些事情，以及掌权者如何回答这些事情： 开发者：我们需要更多的测试来减少bug的数量。 掌权者：不，开发进度已经落后了。你编程的时候动点脑子。你不写bug就不需要解决它们。我们需要新功能，不是测试！ 开发者：这个设计正变得混乱，我们需要重构并提升。 掌权者：不，你一开始想什么了做出这么蹩脚的设计？没人告诉你要设计的这么烂。马上收手把问题解决掉。快到周末了，就用这个周末把它解决掉。 开发者：需求不清晰，他们没有澄清需求，所以我们的工作在最后阶段被否决了。 掌权者：我们花钱雇你就是让你解决问题的。你需要自己想办法解决这些问题。别在这傻坐着了赶紧把我们想要的东西做出来。 现在你应该明白。把团队成员的鼻子放在磨刀石上磨，把脚放在火上烧，软件开发一直是这么干的。Scrum并没有改变这一点。 哎，这真是令人沮丧 嗯，当然，Scrum实际上正试图改变这一切。但是，除非组织的信念和思想真正的发生了变化，旧的管理方式依旧会频繁发生，它每隔几周，甚至每天都在发生。 作为开发人员我们能做什么？ 黑暗Scrum正在滥用Scrum，他们与Scrum试图教给我们的东西明确对立。没有真正的Scrum专家会推荐任何这些做法。正在做这些事的人并没有“做的正确”。每个人都同意这一点。尽管如此，黑暗Scrum真实存在，它还经常发生。在我看来，在人们真正学习Scrum的原则和价值之前，它被滥用几乎是不可避免的。 似乎开发团队除了接受压迫之外别无他法。幸运的是，事实并非如此。好消息是，我们可以做一些强有力的事情。坏消息是，这并不容易。另一个好消息是，它主要是关于编程，我们通常都很擅长这方面。 来自产品负责人和/或其他掌权人的大部分压力来自于他们无法清楚地看到我们正在做什么，我们实际上已经完成了什么。如果我们能清晰的展现出事情的进展，我们可以改变我们的境遇。 如果产品有很多已知的缺陷，我们的领导会认为还有更多，他们会害怕，会把他们的恐惧转化为压力施加给我们，因为恐惧经常表现为愤怒，他们会对我们生气，通常会非常生气。 如果我们在实现功能之前先处理设计或基础设施工作，开发新功能的进展似乎很慢。这使得我们的领导者担心我们会延迟发布或无法提供重要功能。我们将再次遭受他们的恐惧和愤怒的洗礼。 当领导层看不到可工作的软件时，他们会对未来感到害怕 - 这是对的。他们总是以对事情没有助益的方式展现恐惧，这通常是痛苦的。开发人员可以阻止这种情况发生。我知道的唯一方法是提供软件。真实存在，具有可见功能的已经上线的软件！
2019/6/20
articleCard.readMoreBeyond Blockchain 黑客马拉松
Beyond Blockchain Hackathon 我们非常高兴地宣布Beyond Blockchain，这是Gitcoin和ConsenSys Labs联合举办的黑客马拉松。 在过去十年中，区块链社区为新的去中心化的世界建立、资助并扩展了核心基础设施。尽管如此，大多数企业、社区和个人还没有在日常生活中用上这种力量。 现在是时候去参加超越区块链了。超越区块链是一个为期三周的虚拟黑客马拉松，从6月24日到7月10日。来自全球的开发人员、企业家和建设者共同合作将区块链应用推向业务、技术和社会变革的新领域。在此注册！ 超越Blockchain跟随我们之前Ethereal Virtual Hackathon的成功。4月15日至4月30日期间，来自世界各地的500多名开发人员、设计师和企业家加入我们，共同打造基于区块链的项目。总奖金超过67,000美元，由14个区块链公司和企业软件公司赞助。 超越区块链将是一个更有针对性的活动，特别是围绕将区块链工具和技术带给更广泛的受众的主题。出于这个原因，我们将接受赞助商，他们对项目的想法有所建议，这些项目可以建立在影响世界的协议之上。伸出手赞助我们，如果你认为这是你的项目！ 在这个黑客马拉松中，您将有机会与开源维护者一起工作，并以建立区块链的未来而闻名。这包括ConsenSys Labs，您将获得媒体、医疗保健和去中心化的财务方面的奖项。 黑客马拉松细节 您可能想知道，这个黑客马拉松和其他许多黑客马拉松之间的区别是什么？简而言之，我们认为开源社区的开发人员在很大程度上会脱颖而出。Gitcoin生态系统中有20,000名开发人员完成了4000个项目。就在上个月，600多名黑客在短短两周内参与了80次提交。如果您正在寻找一个团队来开展以太坊未来的项目，那么现在是时候放手一搏了。 如上所述，Beyond Blockchain Hackathon将于6月24日至7月10日举行。除了许多发布的奖金之外，黑客马拉松参与者还将争夺超过10,000美元的奖金奖励，这些奖金分布在几个领域，包括媒体、游戏和医疗保健。 我们期待在下周分享更多关于这些奖品和奖金的信息。 立即注册 无论你是否听说过Gitcoin，注册黑客马拉松是一个3分钟的过程。填写此表单，点击右上角的“使用Github登录”创建一个Gitcoin个人资料，您将参加比赛。随着黑客马拉松的临近，我们会通过电子邮件向您通报！当你和你的队友在6月24日开始黑客工作时，我们预计将获得25,000美元的奖金，赏金等等。 点击此处注册为黑客，请访问Gitcoin的网站了解更多详情。 我们很高兴与您一起开发开源项目。 🌳 原文链接
2019/6/18
articleCard.readMoreReputation vs Tokens 声誉和代币
Reputation vs Tokens 声誉和代币 不熟悉DAOstack声誉的读者应该考虑阅读这篇 介绍文章 。 权力下放治理的主题越来越受欢迎，随之而来的是去中心化投票系统的主题。 目前，DAOstack的去中心化治理基础设施主要侧重于支持基于信誉的投票。 在这篇文章中，我们解释了声誉和代币之间的主要区别。 然后，我们讨论了可替代性及其对投票购买的可防御性影响。 最后，我们将审查可以使用信誉或基于代币的投票探索的不同治理模型。 将差异形式化 当我们讨论声誉与基于代币的投票时遇到的最常见的事情是对代币的误解，这导致两者之间可以理解的混淆。 在一些会谈中，我们甚至听到了一个不熟悉的术语“声誉代币”。我们认为，一些混淆与Augur项目命名他们的代币“REP”以及区块链空间中使用的其他单词声誉相关。 。让我们澄清代币的含义以及DAOstack中的声誉。 我们认为区块链上的代币应该包含以下两个属性： 代币不能从其所有者手中夺走。 所有者可以将代币转移给其他任何人，而无需请求许可。 注意：并非所有“代币”都包含这两个属性。 例如，Bancor团队可以禁用 BNT代币的 所有传输 。 他们还可以选择性地销毁（刻录）他们 选择 的任何用户的代币 。 其他人可能不同意，但由于BNT不具备上述两个属性，我们不认为它是一个代币。 既然我们已经理解了代币的这两个属性，那么我们可以更好地理解声誉。 在DAOstack中，Reputation声誉具有以下属性： - 可销毁的：即名义上，它不是真正的属于“你”。只要声誉系统的所有者不选择将其带走，它就属于你。 对于DAOstack，有一个隐藏的假设，即声誉系统所有者不是一个人，而是一个DAO，其行为由DAO的声誉持有者控制。 - 不可转让：即分配了一些声誉的账户既不能转让也不能转账。 这些属性创建了一个非常有趣的结构， 持有声誉的账户在组织中拥有一定的权利 - 在我们的情况下，是投票权。 但是，这种权利远非绝对：在任何时候，组织都可以通过削减账户的声誉来反驳它。 您可以想象，如果利益相关者违反组织的规则，代码强制执行的硬性规则或社会强制执行的软性规则，都可能发生这种情况。 此外，声誉的不可转移性使其实际上不可替代 ，因此该帐户的削减威胁没有到期日期。 因此，没有法定时效：由于五年前犯下的罪行，DAO可以削减账户的声誉。 贿选 在基于代币的投票中，投票购买被视为一种特性（功能）。 基于声誉的系统试图阻止或限制投票购买。虽然确定这些措施的有效性并非易事，但我们在尝试这样做。 首先，区分值得信赖和无信任的投票购买非常重要。 如果卖方和买方可以相互依赖是诚实的，那么交易就是可信的，这种信任通常来自某种社会关系。 如果买方和卖方无法确定对方是否诚实行事，我们称该交易无信任。 在投票购买（我们的系统中的声誉交易）的情况下，我们的声誉版本提供了对信任无信誉交易的强有力的防御。 最天真的例子是出售他的私钥的人。 虽然没有机械方法来阻止私钥的销售，但由于声誉无法转移，买方将始终相信卖方不使用密钥并对其进行投票。 这种投票购买显然需要信任。 此外，DAO可以实施从发现销售其私钥的任何地址剥离信誉的策略。 如果一个密钥的卖方是不诚实的并且保留了一些销售证据，那么他就可以揭示这个证据，并且DAO将剥去该地址的声誉，实际上没收买方的购买。 DAO还可以采取政策来奖励卖家披露这些记录，进一步阻止这种类型的交易。 因此，寻求在声誉系统中购买选票的人有充分的理由不进行无信任的交易。 区块链通常被提出作为解决这个问题的方法 - 使无信任的交易值得信赖 - 但他们并没有绕过这种信誉剥离机制。 例如，有人可能认为使用密钥托管可以在区块链上实现安全，无信任的投票购买。 如果一个人拥有一份持有声誉的合同（与钱包地址相对），他确实可以使用这样一个托管来永久地或在有限的时间内安全地出售该合同的所有权。 这个区块链托管没有做任何事情来防止卖方秘密保存他以前对合同的所有权证明，这意味着这种类型的销售可以被DAO轻易地惩罚。
2019/6/18
articleCard.readMore如何使用DAOstack
如何使用DAOstack 各位网友大家好，如果你到达互联网的这个角落，就意味着你正在考虑参加一个去中心化的自治组织，或者酷孩子有时称之为DAO。 自2016年著名的The Dao hack以来，很少有人相信我们有可能看到一个功能正常的DAO，但我的朋友Matan Field和 DAOstack团队是这个领域真正的先驱，因此他们一直忙于打造难以想象的工作！ 在这篇文章中，我不会详细介绍DAO以及DAO可以实现的内容，我相信 DAOstack 团队以及其他团队提供的内容比我更好。 我也不会关注使用去中心化技术的安全方面，使用本指南需要您自担风险⚠️⚠️⚠️ 我将关注的是把自己加入到目前正在运行DAOstack的 Alchemy 平台的实验性DAO中。 如果你想问任何关于本教程中提到的步骤和产品，欢迎加入bitfwd community (bitfwd.com) Telegram channel at: t.me/bitfwd 译者注：中文可以访问HiBlock官方网站（https://www.hiblock.net） 👩🏼🎤👨🏾💻👧🏻👩🏼🏫🧕🏻🧔🏻🐨🌈⏩ 开始之前，你需要准备的内容如下： 准备清单 科学上网技术：这里有一些工具都需要你会这个技能，如metamask, google docs, twitter, telegram等 浏览器：Firefox是我推荐的浏览器，但你也可以使用Brave或Chrome Metamask: 🦊浏览器插件，可以让浏览器兼容Web3以及轻钱包 ETH: 你需要一点点以太币，来支付提议的手续费 Google Doc或者Github账号: 你需要草拟一份对外的提议，并允许其他人方便的查看该提议且提建议 Twitter账号：可选项，强烈建议用一种工具来证明你的社交关系。LinkedIn以及其他工具都需要人们强制登录。 Telegram 或 Discord: 可选项，因为有需要的加密社区讨论在这2个平台上进行，所以很有用。 准备提议 我们一步一步来看，如果卡住了，欢迎到bitfwd社区提问。 1. 用google docs（或github），撰写声望（reputation）请求提议，可以采用如下参考样例：BoB Jiang’s reputation request proposal.如果你在用google docs，生成文档共享链接时，确保打开“建议”而不是编辑模式，否则其他人可能会搞乱你的提议。 2. 把google doc（或github）链接发布到twiiter上，例如 https://twitter.com/bobjiang123/status/1134387962571923456 3. twitter链接复制到google doc里面，交叉引用 4. 在浏览器里打开Genesis DAO （Alchemy是DAOstack的门户）。会有很多DAO组织加入，Genesis DAO是这个点上的最相关的实验。 5. 假设你已经安装好了Metamask（译者注：需要科学上网），并且你的账号里有以太币，那么久可以开始在Alchemy上提交你的提议 6.
2019/6/18
articleCard.readMore加州CSM共同培训反思及收获
准备 反思 找一个当地的合作伙伴，这样会少去很多的麻烦。 如定场地，酒店，午餐，茶歇等等 对于海外的CSM培训，能早一点确定对于机票会有很大的优惠。 一般提前一个月的机票有很大折扣（但要注意寒假暑假）。 预留出宣传时间，一般最少提前2个月订好课程时间。 收获 这次共同培训的是一名CSP，他正在申请CST。 从培训的课程中，具体收获： 课程主线一定要清晰 课程大纲，授权给学员来创建 对于讲师，守住学习目标的底线 每半天进行一次回顾。回顾学习目标，回顾学习过程 每个学习单元，与学员进行确认是否可以 课程中加入辩论环节（有意思） 加入表演环节（有意思，亮点） 行动 每日问题 你的课程用过哪些有意思的设计环节？方便的话可以共同讨论。 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/5/27
articleCard.readMore我的第一次加州之旅
我的第一次加州之旅 美国来过多次，但加州一直没来过。这次借参加ScrumGathering Austin的机会，来见2个朋友，顺便拜访了一下大名鼎鼎的斯坦福大学。 下面是斯坦福大学的3张照片（主楼区）： 还有一些工程区（Engineering），艺术区的照片，如果感兴趣的可以私聊我分享。 这次加州之旅，先来到旧金山，接下来去洛杉矶（长滩）。 在旧金山经历了几个人生第一次： 第一次飞机早落地30分钟，又原地等待了40分钟（欲哭无泪） 第一次来加州 第一次来旧金山 第一次在美国租车 第一次去斯坦福大学 第一次加油体验 …… 还有很多的第一次 这是我第一次在美国租车，之前一直有担忧，实际开车后发现，大家都很守规矩，比国内好开车。记住规矩： - stop标识符 - yield标识符 - 按标线的车道行驶 - 不随意并线 加油，是一次糟糕的体验。（同一个加油站的加拿大同胞也不会操作） 加油机无法识别信用卡，所以只能预付费。 以下记录旧金山加油站预付费使用过程： 1. 拔下加油枪 2. 放进汽车的油箱口中 3. 别上加油枪的卡子 4. 选择加油的油品（大部分 regular即可，需要根据车型） 5. 1-4准备好之后，就不要动。记住油枪号码 6. 到店内，报油枪号码，预付费一个金额。（需要预估一个数字，半箱油大概20美元） 7. 回加油枪可以看到开始工作了，等加完了。挂枪走人即可。 最后 - 旧金山的气候，真的是一级棒。阳光明媚，气温适宜。 @2019.05 于旧金山机场 行动 每日问题 你最喜欢的城市是哪里？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人
2019/5/25
articleCard.readMore如何成为一名Certified Scrum Master (CSM)
如何成为CSM 0. 参加CSM的课堂培训 在这里你可以找到Bob的CSM课堂培训 1. 培训后的操作 首先恭喜你完成了CSM课堂培训，开启一段敏捷之旅。 接下来就是要参加CSM认证考试： 1. 查看邮箱里来自Scrum联盟的官方欢迎邮件。 2. 登录Scrum联盟，点击右上角My Dashboard进入CSM考试。My Dashboard这里可以查看自己的个人信息，管理Scrum Education Units® (SEUs)，以及（如果你是第一次认证的话）申请免费会员资格。 3. 参加CSM考试，50道题目在60分钟内答对37道题即通过。收到邮件后90天内有2次免费考试机会。（我强烈建议学员在收到邮件后的1周内完成考试）。 4. 通过考试后，回到My Dashboard同意License Agreement。 恭喜你，获得了CSM认证。证书有效期是2年，到期前Scrum联盟会发送邮件提醒。为了维护证书，你需要在2年内完成20个(SEUs)，以及缴费100美元。获得SEU的方式点击这里查看。 要获得更高级的证书，请查看下图： 行动 每日问题 证书只是一个证书，更重要的是学习能力。想要成为自由职业者，可以看这里。 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/5/23
articleCard.readMoreKeynote: The science of timing - midpoints & endings
Keynote: The science of timing - midpoints & endings For midpoint, there would normally be an uh-oh effect, watch out. being slightly behind [at halftime] significantly increases a team’s chance of winning. So how to deal with midpoints: 1. be aware. 2. use midpoints to wake up rather than roll over. 3. Imagine you’re a little behind. (pretend to) What endings do: 1. help us energize. 2. help us encode.
2019/5/22
articleCard.readMoreScrumAlliance Trainer Retreat Update
ScrumAlliance Trainer Retreat Update This is my first trainer retreat, and I am very glad to see many new friends and old friends here. Julie is the facilitator today, and I appreciated her professional facilitation, we are on time to complete the open space. In the beginning, we reviewed the community purpose as following: And then Howard shared the Scrum Alliance new vision as 4C: and the new community teams from Scrum Alliance: I talked with several Scrum Alliance staff, they are excited with new organizational structure, and ready to face the new challenges.
2019/5/21
articleCard.readMore产品待办列表条目的4个类型
产品待办列表条目的4个类型 产品待办列表中可以有很多类型的条目，总结一下大致有4种: 1. 功能性需求（Functional requirement），如特性等新功能 2. 技术改进的需求，如性能要求技术选型的变化，或数据库版本升级等 3. 获取知识的原型，各类线框图等原型 4. 缺陷，主要是生产系统的缺陷 产品列表的条目可以是以上任何一个类型，也可能是多个类型的混合。 这个都没关系，这个分类，主要帮我们思考，都有哪些维度的需求，避免有遗漏。 行动 每日一问：你还知道有哪些类型的产品列表条目？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/5/20
articleCard.readMoreCertified Scrum Master (CSM)考试流程
Certified Scrum Master (CSM)考试流程 考试前 CSM的考试只能参加CST（Certified Scrum Trainer）的授课来获得。 Bob Jiang是一名CST，可以报名参加我的课程。 更多CSM认证相关问题请点这里。 课前预习，请阅读Scrum指南 考试 前提是参加2天的CSM课程 上课后，邮箱内会收到一封来自Scrum联盟的考试邮件（请注意查收垃圾箱） 点开链接（链接类似于这个…………） 更新Scrum联盟会员信息 进入考试（点击 take exam） 选择考试语言（中文 Simplified Chinese、英文都可以选择） 进入考试，50道单选题，考试时间60分钟 答对37道题通过，提交后马上知道结果 考试后 每个学员有2次考试机会，请在考试前认真复习课堂知识和阅读Scrum指南 考试通过后，登录Scrum联盟官网 点击右上角，My Certification Dashboard 找到 print certificate 选择打印类型，有A4和letter的两种类型，哪种都可以 填写证书上显示的名字，支持中文 生成证书，PDF文档。可以下载保存或打印出来。 恭喜你，获得了CSM证书。开启了一段Scrum的冒险之旅。 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.
2019/5/19
articleCard.readMoreCertified Scrum Master常见问题列表
Certified Scrum Master (CSM) 常见问题列表 课程介绍 什么是CSM（Certificated ScrumMaster），敏捷教练认证 答：什么是CSM CSM认证机构为Scrum联盟，是一家国际机构 答：Scrum联盟介绍 CSM和ACP的关系：ACP课程内容中有一个板块是讲Scrum的，可以说ACP涵盖了CSM 答：敏捷认证的对比 上课及考试 CSM考试流程是怎么样的？ 答：CSM考试流程 CSM考试必须参加为期2天的培训。 答：是的。 考试的网站是否要学员注册个人账号？ 答：不需要，讲师会帮助学员注册。 CSM完成培训的当天即可申请在线考试，在申请考试的时候要注意选择中文考试（还有英文的考试） 考试的网站是否要注册个人账号？是否要终身使用此账号（续证等）？ 答：申请在线考试，由老师（Certified Scrum Trainer）发起。考试语言中文英文可以自己选择。需要注册账号，用注册课程的个人邮箱注册。可以一直使用这个账号。 考试时长1个小时，共50道单项选择题，答对37道题通过考试 答：考试有时间限制，1小时。一共50道题目，答对37道题。 CSM考试申请方式简单快捷，拿证快 答：拿证快，但更重要的是课程上学习到的能力，以及回到工作中的实践。 CSM上课不得缺席，否则无法申请考试 答：缺席超过2小时的，将无法申请考试。需要补课后才可以参加考试。 通过CSM考试可在PMI上申请积累16 PDU 答：参加CSM课程（2天）可以申请16个PDU，申请方法 我是一名非技术人员，但很想做敏捷教练，对学习CSM是否有很大难度？ 答：没有难度，CSM课程不需要技术背景。如果了解技术会更容易理解。 CSM认证在线考试在什么时候？中文还是英文？通过率如何？两位老师在认证申请过程会协助哪些事项？多长时间能拿到认证证书？ 答：上课后在线考试，中文英文可以选择，通过率高，老师协助提交邮箱申请考试，考试后通过就拿证。 参加课程取得认证，我需要准备什么？ 答：建议学员认真阅读《Scrum指南》 scrumguides.org 每天上课时间怎样安排的？我是外地学员，考虑住宿等事项需要。 答：上课时间，9:00 - 17:00 CSM证书为电子证书，如何下载？ 答：用自己的账号或邮箱登录Scrum联盟网站；点击右上角个人头像，选择My Dashboard；查找并点击 Print Certificate 链接；选择生成的格式（A4或Letter），然后输入证书显示的名字，点击确认。 纸质证书怎么拿到？ 答：官方不提供纸质证书。
2019/5/13
articleCard.readMore敏捷精髓Scrum精髓
#Scrum的精髓 经常也会叫做敏捷精髓，最最根本就是拆分 + 优化 3个拆分： 1. 拆分时间 2. 拆分产品 3. 拆分组织 2个优化： 1. 优化流程 2. 优化价值 拆分时间 Scrum中固定时间盒（Sprint）就是原来一年的版本，拆小成1-4周的时间盒。 拆分产品 需求条目化。原来是需求一起分析、设计、编码及测试。Scrum中每个需求尽可能小，是一个一个条目。（参考大小，一个Sprint内完成4-10个条目） 拆分组织 大团队拆成小团队，且每个小团队都是端到端的跨职能团队。 优化流程 每个Sprint结束时，团队都会进行回顾会，来优化团队及组织的工作流程。因此每个组织都有自己独特的流程，流程是长出来的。 优化价值 每个Sprint，及工作中，会不断的针对Product backlog进行排序、拆分（优化工作） 行动 每日问题 针对敏捷的精髓，你的观点呢？欢迎留言讨论。 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/5/12
articleCard.readMore敏捷估算
之前我有过一篇博客介绍，如何进行快速有效的估算。 这次介绍一下估算中的故事点，有哪些好处 敏捷估算 敏捷中常用的估算是故事点，今天就谈谈故事点。 故事点本身是没有单位的数字，那么为什么采用这个故事点，主要有2大好处： 方便预测 有效的度量团队开发速率 故事点用于预测 比如团队的速率是每个Sprint（迭代）10-15个故事点，下一版本大概有100个故事点要完成。 那么团队大概需要7-10个Sprint（迭代）来完成下一版本。 度量团队开发速率 敏捷转型之后，很大的一个痛点在于如何度量团队的改进成果。 这里有许多可以度量的维度。 其中有一个度量维度就是团队的开发速率，而故事点是团队开发速率的体现结果。 举个例子： 团队一开始的开发速率可能是10个故事点，随着时间的推移，大概3-5个Sprint后，团队的开发速率提升到12个故事点。 但是如果采用人天（或人小时）来估算的话，就没办法体现出团队的开发速率。 最后 故事点的估算，是针对PBI（产品待办列表条目） 人天（或人小时），是针对任务 不同的估算单位，用于不同的场景。 当然，任务如果拆分的足够小，也可以省略估算。 行动 每日问题 你的团队采用故事点了吗？没有采用的原因是什么？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/5/11
articleCard.readMore东方与西方的文化差异
东方与西方的文化差异有哪些 昨天在过马路（人行横道）的时候，被一辆汽车吓着了，这让我想起在新加坡、美国等地遇到的汽车会主动避让人行横道的行人。 从而激发我想试着找一下东方与西方文化有哪些显示的差异。 过马路时人让车，还是车让人 系统论与还原论 喝热水还是冷水 喝茶还是喝咖啡 靠左走还是靠右走 如果两种文化同时存在，会发生什么情况呢？ 过马路时，人车都麻烦了，不知道谁该让谁。 看问题的时候，是应该看整体还是分开看。 热水还是冷水。 那么在文化发生差异的时候，你会怎么选择？ 如果站在对方的视角，尝试理解对方的感受，你会得出什么结果？ 最后分享一个有意思的事情。 有一次我和一个澳洲朋友一起去参加一个大会， 他选择热水 我选择冰水 他选择茶 我选择咖啡 哈哈…… 行动 每日问题 东西方文化差异还有哪些？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/5/10
articleCard.readMore地主和佃农的关系想到的产品开发
地主和佃农的关系想到的产品开发 土地主（英语：Landlord），又名地主或房东，他们是土地、地皮的业权持有人，通常也是土地使用权的出租者。 – Wikipedia 开始之前，先明确一下地主和佃农这两个角色： - 地主 - 提供土地，土地所有权 - 佃农 - 负责种植庄稼，土地使用权 地主通过出租土地给佃农，收取一定比例的租金。而佃农通过干活，种植庄稼养活自己和家人。 地主这个词，大家首先想到的是“土豪劣绅”。 但历史上的地主并不是这样的，或者准确的说，一开始的地主不是这样的。 明朝之后，地主阶层开始出现。 当时的地主和佃农，大家都是住在一起的（至少是一个村子里）。 在这样一个前提下 - 1. 地主一般会收取少量租金（合适的租金）；总不能不让佃农活下去，那就要闹事了 2. 在发生天灾（比如旱灾、虫灾）的年头，地主还会免租甚至补助佃农；这是赚钱的根本，杀鸡取卵谁都没好处 到这时，地主和佃农之间虽然有租赁关系，但还有一层互助关系。大部分情况下，大家不会破坏这层关系。 什么时候开始，地主变成了土豪劣绅呢？ 事情发生在城市化之后，地主搬进了城市，但还需要有人帮忙收租子。地主就找来代理人收租金。 代理人对地主负责 佃农对代理人负责 代理人和地址之间是雇佣关系（类似经理人模式），缺少亲情道德。 佃农和代理人之间同上。 所以原来的地主和佃农的关系，转换成地主和代理人及代理人和佃农之间的关系。 关系转换之后，地主不必为天灾做出灵活的调整，因为对于地主而言是不可感知（不透明）。 软件开发中的关系思考 对于软件开发，可以从中有哪些启发呢？ 如果做一个映射的话，谁是软件开发中的地主呢，谁又是软件开发中的佃农呢？ 让我们假设公司老板是地主，员工是佃农。 那么老板和员工之间是否有代理人？ 这个代理人和老板及员工的利益是否绑定在一起？ 如果不绑定在一起，会存在什么问题？ 是否很可能变成老板就是“土豪劣绅”呢？ 老板如果想要解决这个问题，可以考虑： 1. 尽可能减少代理人层级。 2. 多在员工中间走动，替员工解决问题。– 这不就是Gemba么？ 3. 代理人需要一种合理的机制，与老板和员工利益绑定在一起。 行动 想了解更多的隐喻，点我查看BoB的课程 每日问题 隐喻是一种很好的思考方式，对于软件开发行业，你还知道哪些隐喻（比喻）呢？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang
2019/5/9
articleCard.readMore敏捷与架构的关系
敏捷与架构的关系 微信群里有伙伴在讨论： > 在敏捷开发中，如何进行架构设计？ 最好的答案是来自于“敏捷软件开发宣言”对应的“敏捷原则”： 最好的架构、需求和设计出自自组织团队。 那对于敏捷开发的团队要不要进行架构设计？ 什么时候进行架构设计？ 如何进行架构设计？ 敏捷开发的团队肯定也是需要架构设计的。 软件开发，不管用什么方式，都离不开架构设计。 对于软件架构的定义如下： 软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。 什么时候进行架构设计 在敏捷开发的过程中，架构设计是渐进的、持续进行的。 如何进行架构设计 架构设计是团队做出的，恰好满足当前业务需求的。 举个例子，如果是一款手机app，刚刚做出来的时候，不需要过多考虑并发（如1000个并发）；而是满足业务流程即可。 在敏捷开发的过程中，关键的点在于透明性及适应和调整。 不管采用什么架构，都需要是团队做出的决定。 团队都知道选择这个架构的原因是什么， 以及有什么缺陷 后续什么时候需要对这个架构进行改造 等等 行动 每日问题 在敏捷开发过程中，你们的软件架构是如何进行的？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/5/9
articleCard.readMoreScrum Master必读材料
Scrum Master八个姿势系列白皮书 Scrum Master八个姿势系列白皮书 Scrummaster必读书单 敏捷书单大全 如果好的材料推荐，欢迎给Bob发邮件： bob@bobjiang.com
2019/5/5
articleCard.readMoreScrum联盟中文
敏捷认证的对比 - 敏捷认证的对比 什么是CSM（Certified Scrum Master） - CSM（Certified Scrum Master）介绍 - 如何成为CSM - Certified Scrum Master CSM常见问题清单 - CSM考试流程 - CSM常见问题清单 SEU介绍 - SEU（Scrum Education Unit）介绍 Scrum联盟与其他机构对比 - Scrum联盟介绍及与其他机构对比 关于BoB Jiang
2019/5/5
articleCard.readMore为什么Scrum指南中移除燃尽图
为什么Scrum指南中移除燃尽图 Scrum指南尝试只保留最重要最基本的核心元素。那么燃尽图的作用是什么需要了解。 燃尽图，其最主要有如下作用： - 体现团队的进度，从而暴露问题 - 团队根据进度、或暴露的问题，进行调整 达到上述目的，用Scrum中的Sprint Backlog就可以。 Sprint Backlog 燃尽图是一种实践，是辅助Sprint Backlog的一种实践。除了燃尽图，我们还可以用任务板等方式来实现Sprint Backlog。 下图是一个任务板（Sprint Backlog）的样例。 行动 每日问题 你的团队还在用燃尽图吗（尤其是手绘的）？有没有其他可视化的方式来实现Sprint Backlog呢？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/5/5
articleCard.readMore获取SEU（Scrum Education Unit）的6个方法
获取SEU（Scrum Educational Unit）的6个方法 Scrum Education Units® (SEU®) 为了验证您的参与以及对Scrum基本原则和实践的持续熟练程度，并保持您的认证，您需要通过完成教育培训或学习机会来获得Scrum教育单元（SEU）。这很容易做，并将帮助您保持市场的相关性（和竞争力）。 SEU遵循1：1的比例，其中一小时的参与或准备等于一个SEU。有六类SEU（6个方法）。向下滚动以查看每个类别的概述。虽然我们建议您将SEU体验分散到多个类别以体验多样性，但您只需填写SEU总量即可维护、续订您的认证。 更新基础、高级和专业级认证都需要SEU。这包括CSM®，CSPO®，CSD®，A-CSM℠，A-CSPO℠，CSP®-SM，CSP®-PO和CSP®。 SEU还可用于为那些完全通过Certified Scrum Developer®（CSD®）认证的人员获得CSP。了解CSD如何通过CSP获得SEU。 SEU类别 类别A的活动： 参加如下活动都可以获得SEU，如Scrum联盟的 Global Gathering, Regional Gathering, Scrum Coaching Retreats，及其他Scrum联盟赞助的活动、还有Scrum联盟支持赞助的用户组活动等。 注：中国每年有 Regional Scrum Gathering, 详情参考。 演讲、教练及参与都算作SEU相关的活动。 另外，Scrum联盟认可Scrum Gathering中交流的价值，所以参与Scrum Gathering也可以获得SEU。每天最多8个SEU。 分类A的选项： - A.1 参加 Global Scrum GatheringSM - A.2 参加 Regional Scrum GatheringSM - A.3 参加 Scrum Alliance 用户组活动 - A.4 参加 Scrum Alliance-sponsored event - A.5 参加 Scrum Coaching Retreat - A.6 参加 Scrum Alliance CSP Retreat - A.
2019/5/4
articleCard.readMore探秘Scrum机构 - Scrum联盟和Scrum.org对比
探秘Scrum机构 - Scrum联盟和Scrum.org对比 简介 Scrum联盟是一个非盈利机构，旨在“改变工作的世界”。 Scrum.org是一个盈利机构，旨在“改善软件交付行业”。 对比 Scrum联盟的使命是“改变工作世界”，scrum.org的使命是“改善软件交付行业”。 Scrum联盟是一个非盈利组织，scrum.org是一家盈利公司。 Scrum联盟计划强调学习经验，包括讨论，模拟，应用等，scrum.org计划强调通过在线测试。 Scrum联盟培训适用于“工作世界”，scrum.org培训适用于软件开发应用。 Scrum联盟有教练计划（CTC，CEC和免费在线教练培训），scrum.org没有（除了作为ScrumMaster角色的一个子集）。 有一些优秀的scrum.org培训师，但PST（Scrum.org的培训师）要求不会很高，但成为Scrum Alliance CST的标准要比PST高很多。 Scrum联盟认证企业教练（CEC）也是一个非常高的标准。 两者都比像SCRUM study这样的复制更可靠，他们教授大量的方法来记录的项目。400页误导性地称为“Scrum”，但不是轻量级项目无关的Scrum。 原文作者：Rowan Bunning 八卦 与Scrum相关的机构有如下几个：（欢迎读者补充） - Scrum联盟 - scrum.org - scruminc - LeSS - Scrum@Scale - SAFe - 国内Scrum机构就不一一列举，基本分为2大派别（一派是Scrum联盟体系，一派是PMP体系） 八卦来啦………… 2001年Ken Schwaber、Mike Cohn、Esther Derby三人发起了Scrum联盟 2005年（或2006年）Ken出走离开了Scrum联盟成立了scrum.org 2007年 Jeff Sutherland成立ScrumInc 2005年 Craig Larman & Bas Vodde开始实践LeSS框架 2011年 Dean Leffingwell成立SAFe 行动 你所在的行业，有哪些机构，你对这些机构的认知是怎么样的？ 这是构建一个行业认知的好机会。 每日问题 如果你来构建一个培训机构，你会从哪儿开始？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang
2019/5/3
articleCard.readMoreScrumMaster的十大错误
ScrumMaster的十大错误 敏捷进入中国有18年了，现在各个行业都在说敏捷，每个ScrumMaster都在说scrum。本身这是个好事，可是出现了很多“敏捷大仙”。用各种预定义的流程、工具、文档替代了敏捷，这已经背离了敏捷的精髓，敏捷的本质。 注明：BoB在工作中也碰到了很多敏捷的误区，与作者深有同感。 1. 因为敏捷而敏捷 其实大家并不关心敏捷，而是关心敏捷背后的那个“快”。（我有一篇文章专门描述，敏捷不是快）。除去“快”，敏捷更应该关注目标及个人成长。 ScrumMaster的口头挂着“敏捷、Scrum、看板”，经常会说敏捷要求我们做这个，敏捷要求我们做那个，blah,blah…… 这个不是答案，敏捷也不仅是项目管理工具或流程。敏捷更多是一种心态的改变。 敏捷应该帮助企业和个人实现目标（即价值）。 团队成员不想开每日站会，讨厌计划会，回顾会。为什么？因为团队认为敏捷是另一套流程，我已经996了，还要加这么多会议，不如去写代码。 在敏捷转型的过程中，“拒谈敏捷”，认真思考如下问题： 你的目标是什么？ 为了达到目标，你需要什么？ 达到目标的阻力是什么？ 你怎么知道达到目标了？ 敏捷里面有非常多的实践了，比如Scrum的5个会议，看板，用户故事，等等。但是用每个实践之前，尝试回答上面的问题，并且和团队一起来回答。 2. 管理心态 ScrumMaster不用管人，而是帮助改进系统，提升公司和个人价值以及移除障碍。ScrumMaster并不是角色，也不是头衔。 作为ScrumMaster，是与团队在一起帮助团队完成工作。提供团队的需要，解决团队的问题。 良好的ScrumMaster观察团队工作，使之透明并识别改进机会。 3. 推敏捷 不要向团队推敏捷，推工程实践。而是让团队主动用敏捷方法。 参考我之前的文章，推还是拉敏捷 让团队决定他们要如何解决问题。团队需要时间成长。 4. 4W1H（Who, What, When, WHere, How） ScrumMaster主动的什么也不做。表面上什么也不做。产品开发是客户、产品负责人及团队的工作。作为ScrumMaster是帮助团队成长，改进系统。 下面这些对于ScrumMaster很常见： - 分配任务 - 编写用户故事 - 提前规划迭代列表 - 估算 - 更新任务板 - 认为对所有问题负责 - 选择配置scrum工具 - 决定什么是团队的障碍 - 计算团队成员的能力（容量） 认真思考一下，作为ScrumMaster你有没有做过类似的事情。如果做过，请认真反思。 5. 定义团队协议及DoD ScrumMaster和团队一起共同制定团队协议、DoD，而不是代替团队，一个人制定好。询问团队他们想要什么样子的协议，DoD。 这是团队的事情，作为ScrumMaster，是帮助团队制定协议和DoD。 让团队理解协议和DoD的好处，并制定出来。 6. 定义需求或任务 ScrumMaster是帮助产品负责人和团队的，但产品负责人和团队要做他们自己的工作。 产品负责人不准备产品路线图，不提前准备需求，不去和干系人或真实客户探讨，不梳理产品列表。 作为ScrumMaster，需要帮助产品负责人认识到这些问题，并提供相应的工具，辅助产品负责人。 7. 定义优先级及计划 不要成为产品负责人的代理，永远不要。 产品列表的优先级（顺序）是产品负责人的职责，ScrumMaster可以帮助产品负责人认识到： - 如何排序 - 排序的参考因素 - 什么时间排序 - 什么时间准备好产品列表
2019/5/2
articleCard.readMore推荐敏捷书单大全
最近推荐了一系列敏捷书单，总结如下： Scrum好书 工程实践书单 敏捷教练书单 产品经理书单 引导书单 行动 如果你有其他好书，或者书单要推荐，欢迎联系BoB。 每日问题 你在读什么书呢？ 与BoB面对面 报名BoB的敏捷认证课程 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/5/1
articleCard.readMore引导书籍推荐
推荐引导书籍 昨天有学员问，老师有没有引导的书推荐。在推荐书单之前，简单介绍一下引导。 引导也是一个舶来品，国际有几个权威的机构（引导协会），其中一个有名的是IAF（国际引导者协会）. 由IAF定义了引导者的6大核心能力： 创造合作的客户关系 规划合适的团队流程 创造并维持一个参与式的环境 引导团队达成适当且有用的成果 建立并维持专业的知识 展现正向且专业的态度 书单如下： 引导 : 团队群策群力的实践指南 作者: 英格里德·本斯 出版社: 电子工业出版社 副标题: 团队群策群力的实践指南 原作名: Facilitating with Ease!: Core Skills for Facilitators, Team Leaders and Members, Managers, Consultants, and Trainers 译者: 任伟 简介： > 引导，是一项能够有效调动一群人的积极性、促进高质量合作的能力，它已经成为当今经理人、团队领导、部门经理、教育培训工作者的一项核心能力。也是建设学习型组织、提高团队决策力的重要方法。本书提供了团队引导的核心技能和过程工具，包括问题清单、评估要素、决策方法等，它们均来自于近二十年间各种场合被验证过的有效的实践经验，适用于组织内外部的引导者在工作场所、团队会议、甚至任何需要调动大家群策群力的场合。 引导的秘诀 作者: 迈克尔·威尔金森 (Michael Wilkinson) 出版社: 电子工业出版社 副标题: 通过团队合作获得结果的SMART指南 引导工具箱 作者: 森时彦 / 引导工具箱研究会 出版社: 电子工业出版社 副标题: 解决组织问题的49个工具 谁说我们不能一起做决定？ 作者: 山姆肯纳 出版社: 开放智慧引导科技 副标题: 参与式决策引导宝典 简介： > 议而有决、决而有行的秘诀世界上有大量的会议。全美国每天发生两千五百万个以上的会议，全世界每天更有八千五百万个以上的会议进行。不管是企业团队或民间团体，要让会议更有效地运作是一项终身的挑战。本书所介绍的团体动态、会议引导与建立共识工具的察觉与熟练的技巧，是提升团体会议效能不可或缺的。团体运作与决策得以更灵活、深入与迅速。而引导式的思维、行为与工具，能引发团队承诺感，创造卓越绩效，也是实现所谓学习型组织的关键。
2019/4/30
articleCard.readMore敏捷认证对比
本文将对比市场上的敏捷认证，希望给想要拿证的本本族一点点参考。 市面上现有的敏捷认证 Scrum Master认证 CSM（Certified Scrum Master） PMI-ACP（Agile Certified Practitioner） Exin Agile Scrum Master PSM（Professional Scrum Master） 大规模敏捷认证 (后续对比) SAFe LeSS Scrum@Scale NEXUS Disciplined Agile Delivery Enterprise Scrum 对比维度 本文尝试从以下几个维度来进行比较： 创建时间 创建人或者组织 现有认证会员数 课程面向对象 CSM（Certified Scrum Master） 先简单介绍一下CSM，可以参考我的一篇博文“什么CSM”。 创建信息 CSM是最早的一个敏捷认证（至少我的记忆如此，如果有不同的信息，麻烦告诉我一下），它是由Scrum联盟进行颁发的。Scrum联盟由Ken Schwaber（Scrum之父）、Mike Cohn及Esther Derby等人成立于2001年。 现有认证会员数 目前Scrum联盟是全球最大最有影响力的敏捷组织之一，拥有超过91万的CSM认证会员。 课程面向对象 Scrum联盟的认证体系比较完善，大家可以参考Scrum联盟网站。其中CSM是专门面向Scrum Master的认证，可以参加培训的人员有：Scrum初学者、管理人员、传统项目经理、团队成员等。 通过Scrum联盟的网站看到，它的认证体系从入门（CSM，CSPO，CSD）到进阶（CSP），到导师级（CST，CEC，CTC）都有很详细的介绍，是一套完整的体系设计。 注：新版的认证体系又做了新的调整，如下图： PMI-ACP（Agile Certified Practitioner） 创建信息 ACP认证是由PMI机构于2011年创建发起的，PMI也是全球最大的项目管理认证机构。不过目前PMI只有这一个敏捷认证，让人对其体系化有一点点存疑。【注：在PMI的认证体系中，PMP项目管理还是占了绝大部分（有PMP，PgMP，还有其他各种项目管理层面的认证）。而新兴的敏捷ACP认证只有这么一个证书。】 现有认证会员数 互联网查到的部分数据显示，截止到2016年底，ACP会员数不到2万。(数字待更新) 课程面向对象 ACP认证设计的初衷是one size fits all，即一个认证解决敏捷所有问题。这个只能呵呵一下。 PSM（Professional Scrum Master） 创建信息 PSM是由scrum.
2019/4/30
articleCard.readMore产品管理书籍推荐
推荐产品管理书籍 产品管理是一个组织敏捷转型的重点，产品方向需要不断探索，不断调整。 下面推荐一些和产品管理相关的书籍： 启示录 结网@改变世界的互联网产品经理 上瘾 跨越鸿沟 人人都是产品经理 游戏化实战 设计冲刺 疯传 网易一千零一夜 腾讯方法 启示录 作者: [美] Marty Cagan 出版社: 华中科技大学出版社 副标题: 打造用户喜爱的产品 原作名: Inspired: How To Create Products Customers Love 译者: 七印部落 内容简介： > 为什么市场上那么多软件产品无人问津，成功的产品凤毛麟角？怎样发掘有价值的产品？拿什么说服开发团队接受你的产品设计？如何将敏捷方法融入产品开发？过去二十多年，Marty Cagan作为高级产品经理人为多家一流企业工作过，包括惠普、网景、美国在线、eBay。他亲历了个人电脑 、互联网、 电子商务的起落沉浮。《启示录：打造用户喜爱的产品》从人员、流程、产品三个角度介绍了现代软件（互联网）产品管理的实践经验和理念。七印部落正在翻译作者的博客和授课视频，欢迎访问微博：https://weibo.com/7seals 结网@改变世界的互联网产品经理 作者: 王坚 出版社: 人民邮电出版社 副标题: 改变世界的互联网产品经理(修订版) 内容简介： > 《结网@改变世界的互联网产品经理(修订版)》以创建、发布、推广互联网产品为主线，描述了互联网产品经理的工作内容，以及应对每一部分工作所需的方法和工具。产品经理的工作是围绕用户及具体任务展开的，《结网@改变世界的互联网产品经理(修订版)》给出的丰富案例以及透彻的分析道出了从发现用户到最终满足用户这一过程背后的玄机。新版修改了之前版本中不成熟的地方，强化了章节之间的衔接，解决了前两版中部分章节过于孤立的问题；同时，穿插增加了一些移动互联网方面的数据、案例和方法介绍，与时俱进移动互联网时代。 《结网@改变世界的互联网产品经理(修订版)》面向现在正在从事及未来将要从事互联网相关工作的创业者和产品经理，也可以作为互联网产品策划人员或相关专业学生的参考书。 上瘾 作者: [美] 尼尔·埃亚尔 / [美] 瑞安·胡佛 出版社: 中信出版集团 副标题: 让用户养成使用习惯的四大产品逻辑 原作名: Hooked: How to Build Habit-Forming Products 译者: 钟莉婷 / 杨晓红 内容简介： > 《上瘾》揭示了很多让用户形成使用习惯，甚至“上瘾”的互联网产品服务背后的基 本设计原理，告诉你怎样打造一款让用户欲罢不能的产品。作者根据自己多年的研究、咨询及实际经验，提出了新颖而实用的“上瘾模型”（Hook Model），即通过四个方面来养成用户的使用习惯。通过连续的“上瘾循环”，让用户成为“回头客”，进而实现循环消费的终极目标，而不是依赖高昂的广告投入或泛滥粗暴的信息传播。
2019/4/29
articleCard.readMore敏捷教练书籍推荐
推荐敏捷教练书籍 敏捷教练是一个“新兴”的职位，对于这个新职位，他都有哪些技能要求，如何自我提升呢？ 看一下下面的书单： 敏捷教练 如何构建敏捷项目管理团队 : ScrumMaster、敏捷教练与项目经理的实用指南 敏捷软件开发 : 原则、模式与实践 敏捷回顾 : 团队从优秀到卓越之道 敏捷革命：提升个人创造力与企业效率的全新协作模式 Scrum敏捷项目管理 敏捷开发的艺术 敏捷项目管理 30天软件开发 : 告别瀑布拥抱敏捷 敏捷武士 : 看敏捷高手交付卓越软件 敏捷教练 作者: [英] Rachel Davies / [英] Liz Sedley 出版社: 清华大学出版社 副标题: 如何打造优秀的敏捷团队 原作名: Agile Coaching 译者: 徐毅 / 袁店明 内容简介： > 《敏捷教练：如何打造优秀的敏捷团队》取材于国际知名敏捷教练的真实经历，展示了他们在辅导团队进行敏捷实践过程中所积累的辅导技巧，凝聚着他们在对敏捷辅导的真知灼见，每章还针对特定主题总结了在转型过程中教练和团队可能面对的障碍及其应对方案。 《敏捷教练：如何打造优秀的敏捷团队》具有较强的实用性和指导性，适合项目经理、技术总监和敏捷团队的所有成员阅读与参考。 如何构建敏捷项目管理团队 : ScrumMaster、敏捷教练与项目经理的实用指南 作者: 丽萨·阿金斯 出版社: 电子工业出版社 副标题: ScrumMaster、敏捷教练与项目经理的实用指南 译者: 徐蓓蓓 / 白云峰 / 刘江华 内容简介： > 《敏捷项目管理系列丛书•PMI-ACPSM考试指定教材•如何构建敏捷项目管理团队:ScrumMaster、敏捷教练与项目经理的实用指南》结合作者的亲身经历告诉读者如何建立一个高性能的敏捷项目管理团队，以及最终成为一名优秀的敏捷教练。作者将敏捷教练定义为导师、协助者、老师、问题解决者、冲突领航员、协作指挥者，正是这种不同角色之间的细微区别才使敏捷教练的工作富有深度。《敏捷项目管理系列丛书•PMI-ACPSM考试指定教材•如何构建敏捷项目管理团队:ScrumMaster、敏捷教练与项目经理的实用指南》不仅能帮助敏捷教练、培训师、导师、协助者提升自身表现，而且对所有敏捷开发组织中身处领导岗位的人在构建敏捷项目管理团队方面提供指导和帮助，对希望成为高效敏捷项目管理团队一员的人也可以从《敏捷项目管理系列丛书•PMI-ACPSM考试指定教材•如何构建敏捷项目管理团队:ScrumMaster、敏捷教练与项目经理的实用指南》中获益。 敏捷软件开发 : 原则、模式与实践 作者: [美] Robert C·Martin 出版社: 清华大学出版社 副标题: 原则、模式与实践 原作名: Agile Software Development: Principles, Patterns, and Practices 译者: 邓辉 内容简介： > 在本书中，享誉全球的软件开发专家和软件工程大师Robert C.
2019/4/28
articleCard.readMore软件工程实践书籍推荐
推荐软件工程实践书籍 Scrum转型想要做好，第一步先了解并真正落实Scrum，那么我推荐的Scrum书籍是要看懂并实践的。第二步是团队的工程实践要做扎实。 下面推荐工程实践书单： 重构：改善既有代码的设计 解析极限编程 : 拥抱变化 代码整洁代码 程序员的职业素养 修改代码的艺术 编写可读代码的艺术 测试驱动开发 : 实战与模式解析 Cucumber：行为驱动开发指南 实例化需求 驯服烂代码 重构：改善既有代码的设计 作者：Martin Fowler 出版社：人民邮电出版社 译者：熊节 链接：https://item.jd.com/12584498.html 内容简介： > 重构，一言以蔽之，就是在不改变外部行为的前提下，有条不紊地改善代码。多年前，正是本书原版的出版，使重构终于从编程高手们的小圈子走出，成为众多普通程序员日常开发工作中不可或缺的一部分。本书也因此成为与《设计模式》齐名的经典著作，被译为中、德、俄、日等众多语言，在世界范围内畅销不衰。 本书凝聚了软件开发社区专家多年摸索而获得的宝贵经验，拥有不因时光流逝而磨灭的价值。今天，无论是重构本身，业界对重构的理解，还是开发工具对重构的支持力度，都与本书最初出版时不可同日而语，但书中所蕴涵的意味和精华，依然值得反复咀嚼，而且往往能够常读常新。 解析极限编程 : 拥抱变化 作者：Kent Beck / Cynthia Andres 出版社：机械工业出版社 译者：雷剑文 / 李应樵 / 陈振冲 链接：https://item.jd.com/31536602426.html 内容简介： > 极限编程（XP）是适用于中小型团队在需求不明确或者迅速变化的情况下进行软件开发的轻量级方法学。本书是XP宣言，也是第一本有关XP的图书。 这本书介绍了XP背后的思想——它的根源、哲学、情节等。它将帮助读者选择是否在项目中使用XP时做出明智的决策。本书的另一个目的是帮助那些已经在使用 XP的读者更好地理解它。 对程序员而言，XP做出的承诺是他们每天能够处理真正重要的工作，而不必单独面对令人担忧的状况。他们将能够集中全力来使他们的系统获得成功。他们将做出最适合由他们来做的决策。对于客户和管理人员而言，XP的承诺是他们将从每个编程周期中获得最多的利益。他们将能够在开发的中途更改项目的方向而不用承担太高的成本。 本书适合所有软件开发人员、管理人员参考。 代码整洁之道:程序员的职业素养 作者：罗伯特·C.马丁 (Robert C.Martin) 出版社: 人民邮电出版社 原作名: The Clean Coder:A Code of Conduct for Professional Programmers 译者: 余晟 / 章显洲 链接：https://item.
2019/4/27
articleCard.readMoreScrum书籍推荐
推荐Scrum书籍 直接上干货，推荐书籍清单如下（推荐有顺序的哦） Scrum指南 Scrum精髓 Scrum敏捷软件开发 Scrum捷径 硝烟中的Scrum和XP : 我们如何实施Scrum 敏捷软件开发:Scrum实战指南 Scrum要素 大规模Scrum:大规模敏捷组织的设计 用户故事地图 用户故事与敏捷方法 Scrum指南 作者：Ken Schwaber & Jeff Sutherland 出版社：Online 译者：Jiancheng Zhou 链接：https://scrumguides.org/ 内容简介： Scrum 是用于开发、交付和持续支持复杂产品的一个框架。本指南包含了 Scrum 的定义，其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则。Ken Schwaber 和 Jeff Sutherland 创造了 Scrum，Scrum 指南也由他们撰写并提供。总之，他们是 Scrum 指南的后盾。 Scrum精髓 作者：Kenneth Rubin 出版社：清华大学出版社 译者：姜信宝 / 米全喜 / 左洪斌 / （审校）徐毅 链接：https://item.jd.com/11462889.html 内容简介： > 短短几年时间，Scrum跃升为敏捷首选方法，在全球各地得以普遍应用。针对如何用好、用巧这个看似简单的框架，本书以通俗易懂的语言、条理清晰的脉络阐述和提炼出Scrum的精髓。全书共4部分23章，阐述了七大核心概念：Scrum框架，敏捷原则，冲刺，需求和用户故事，产品列表，估算与速率，技术债；三大角色：产品负责人，ScrumMaster，开发团队以及Scrum团队构成：Scrum规划原则及四大规划活动：多层级规划、产品组合规划、产品规划和长期规划；冲刺四大活动：规划、执行、评审和回顾。 本书取自作者十多年的实践经验，对员工个体和管理层都具有重要的指导和参考意义，可以帮助企业顺利导入Scrum，在动态的商业环境中以积极心态拥抱变化，做出优秀、卓越的产品，走上创业、守业、常青基业的成功之路。 Scrum敏捷软件开发 作者：Mike Cohn 出版社：清华大学出版社 译者：廖靖斌 / 吕梁岳 / 陈争云 / 阳陆育 链接：https://item.
2019/4/26
articleCard.readMore领导者和管理者
领导者和管理者（leader vs. manager） 领导者和管理者的区别 领导者有着明确的主人意识。领导者和管理者有很多相似之处，如他们都承担了管理职责。而管理者是为数字服务的。 领导者重点是凝聚共识，而管理者的重点是控制员工。 The main difference between leaders and managers is that leaders have people follow them while managers have people who work for them. 作为一名领导者，可能会具备以下的特质： 正直（Authentic） 愿景 同理心 沟通 管理者是一个头衔（title），而领导者不需要头衔。 如上图那样，作为领导者，是身先士卒的人，是要自己动手的。而管理者是在用嘴指挥，并不亲自动手。 思考 看到上面的领导者的描述，其实想当一名领导者没有那么难。他不需要某个人授权你来做，而是只要你自己行动就可以。 分享给大家一个视频，成为领导者（如何引领一项运动）。 行动 《Scrum精髓》这本书已经翻译好久了，但在国内还有好多人并不了解Scrum的本质。 如果你想深入了解Scrum，欢迎加入Scrum精髓读者群。请加微信： hiblocknet ； 添加微信后，发送消息 scrum 每日问题 你想在某个方面引领运动吗？其实并不难，关键在于行动起来。 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.
2019/4/25
articleCard.readMore网站地图之搜索引擎收录
网站地图之搜索引擎收录 无意中发现我的博客从2015年起，并不在谷歌搜索引擎的收录中。即你在谷歌是查不到我的博客内容的。 既然发现问题，就要定位问题出在哪儿，以及修复它。 定位问题 使用google search console，把网站加进去。 需要网站的DNS域名增加一条TXT记录，用来确认你是网站的站长。 确认后，检查网站链接的有效性。如下图，点击“网址检查” 输入你网站中的任何网址，如可以输入 bobjiang.com (BoB的博客) 检查报告如下： 我的博客还未完全恢复，显示Google仍未收录。 这里根据报告，就可以找到详细的问题描述，以及更多帮助信息。 我的网站提示为被 robots.txt 禁止抓取。 解决问题 既然被 robots.txt 禁止抓取，检查网站博客中的所有文件后未发现 robots.txt 。 咨询博客提供商（海波同学），发现有一处关键设置，即是否允许机器人设置为 yes。修改为 no 后即可。 为了更快恢复所有的抓取，需要生成网站地图。 这里有谷歌推荐的第三方网站地图生成工具列表[1]. 有5类： - 可部署的服务器端程序 - 内容管理系统（CMS）插件，如大名鼎鼎的 wordpress - 可下载的工具（如windows，Mac系统的） - 在线服务 - 自带网站地图的CMS系统 我选择了在线服务（不用部署、不用下载，但可能有一定的限制）： XML sitemap generator 生成网站地图 填写对应的网站信息，如图： 点击按钮 Generate sitemap 生成后，点击下载 sitemap XML file 上传sitemap.xml文件到网站目录，如我的上传在网站根目录： https://bobjiang.com/sitemap.xml 返回 google search console 点击左侧导航栏的 索引 - 站点地图，结果如下图：
2019/4/24
articleCard.readMore物以类聚 - Scrum特性团队之社区
物以类聚 - Scrum特性团队之社区 今天读到 Scrum模式社区 中的一个模式（物以类聚 - Bird of Feathers），觉得很有启发。 公司或组织内，往往是用层级方式（加上组件团队或职能团队）来搭建组织结构。 这个方式非常符合我们的学习方式，即还原论方式。 把一个系统切分成若干个小块，然后认真学习其中的每一块。（西方哲学的基础是还原论[1]） 看一下我们的组织（或公司），是不是也是拆分成很多的小块，然后期望每一块都可以做到极限的效率。 Scrum的重要基础是特性团队（特性团队有两个阶段，后续可以讨论）。据我观察，愿意且能够组成特性团队的公司不超过10%。 原因呢，我猜测是不好管理。试想一下，是把同样技能的人放在一起好管理，还是特性团队好管理。（这里的管理指的是直接可见的效率数字，如KPI等） 而反直觉的特性团队，会给产品开发带来巨大的收益。 比如Spotify的例子，很多人都在研究，如下图： 这个图中的Squad就是特性团队，而Chapter是类似于职能、技能。 需要项目经理看到这个图后，都会跟我讨论是弱矩阵还是强矩阵。 其实这个根本不是矩阵。 只有一个方向 Squad 的负责人是PO（即产品负责人），另 Tribe 会有管理者。Chapter的负责人不是管理者。而不论是Chapter也好，Guild也好，都是某种形式的社区。即同类的人。 对于公司来讲，赚钱（盈利）是首要目的。因此以首要目的来组织人员没有问题。 至于相同技能、兴趣的人，是以非正式的社区形态存在。（如果公司小，可以考虑和外部社区进行关联） 如下图是另外一个呈现的形式： 原文链接 参考资料 [1] 还原论 https://zh.wikipedia.org/zh-hans/%E8%BF%98%E5%8E%9F%E8%AE%BA 思考 组织结构永远不可能有完美的，但一定要记住，无论怎么调整结构，都是为组织目标服务的。（产品是核心） 每日问题 你的组织结构是怎么样的，你会怎么调整？（虽然不一定有权限，但这个是作为管理层必备的技能） 欢迎加入自由职业者俱乐部 微信群，请加微信： baobaotalk_com ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者
2019/4/23
articleCard.readMore深入理解ScrumMaster的技能
深入理解ScrumMaster技能之教练技能 在我的上一篇文章中介绍到 ScrumMaster的技能要求。 微信群中有伙伴问到，教练能力指的是什么。 我当时的回答有点略显简单 – 敏捷教练和球队的教练类似，是团队教练技能。 现在展开来描述一下。 教练的起源 公认的教练起源是来自《网球游戏》（The Inner Game of Tennis）这本书。作者 Tim Gallwey 是一名网球教练，有一次他因为临时有事不能教一个学员，他就找了一名滑雪教练来代替他。等他回来发现学员的进步超出他的预期。 然后他就反思，这中间的差异是什么。为什么会产生这样的结果。 Tim 曾当众打赌说，他可以在20分钟内“教”会任何一个人打网球，点击这里查看完整的故事。 ICF定义教练： 教练通过发人深省和富有创造力的对话过程，激发客户自身寻求解决方案的能力和采取行动的改变，最大限度地激发个人天赋潜能和职业潜力, 实现个人价值，成为生活和事业上的赢家。 无论教练用于哪个方面，教练的核心是相信每个人的内在智慧，每个人心中都有自己的答案。做为个人，相信自己的能力，并活出自己的天赋；做为管理者，相信并激发员工的潜能；做为父母，相信并激发孩子的潜能。 通过教练定义和故事，我们了解到： 每个人都具备能力（内在的力量） 相信自己可以做到（打破固有的思维束缚） 放手去做（需要一个教练在旁边鼓励） ScrumMaster如何做好教练角色 从我个人的经验来看，有以下几步： 相信团队有能力解决问题 让团队放手去尝试 时刻关注团队，提出有力量的问题（当团队的镜子） 时刻关注目标（产品目标，团队目标） 能做好这几点已经很不易。如果想找一些具体的观察点，可以参考： ScrumMaster检查清单 思考 做事需要有清单，不论对于ScrumMaster还是对于Product Owner。清单可以让我们的工作、生活变得简单。清单可以作为第一步，后续需要不断优化清单。 每日问题 你在工作中还有哪些清单？方便的话可以留言分享一下。 欢迎加入自由职业者俱乐部 微信群，请加微信： baobaotalk_com ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer）
2019/4/22
articleCard.readMore张弛有度（个人反思）
张弛有度 今早在冥想的时候状态很不好，做了10分钟就停了。然后反思的时候我在想为什么呢？ 心不静，所以思绪混乱，然后身体也有反应了。 这里有3个层面： 心 （内圈） 身体 （中间） 思维 （外圈） （让我想起手脑心 3H） 心 这三个层面，是互相影响的。 心是最内圈，心情要平静。 教练状态里面有一句话叫做 接纳当下的一切，这个就代表的是心情。以一颗平常心来面对当下。 身体 身体状态如果不好，影响是多个方面的，连带影响心情和思维。 所以锻炼身体这是个世界难题。 思维 心情平静，身体状态是ok的，才能做到思维是自由的。 否则很容易思维是乱的，不容易琢磨。 上述三个层面，都有训练方法（紧张），也有放松方法（松弛）。 我们想要做到松弛有度，就要不断的训练与放松 心、身体、思维。 思考 如何训练与放松，这是个难题。我也在不断摸索中，可以先从简单的做起（身体）。 每日问题 你平时是如何进行各种训练与放松的呢？欢迎参与分享。 欢迎加入我有一个梦想 - 自由职业者俱乐部 微信群，请加微信： baobaotalk_com ； 添加微信后，发送消息 dream 广告时间 订阅邮件列表 - 我有一个梦想 和BoB面对面学习Scrum 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人
2019/4/21
articleCard.readMoreScrumMaster的技能要求是什么
ScrumMaster的技能要求是什么 开始这个话题前，引用王存浩的两个问题：(今天存浩的分享–时间线方式对我启发很大，感谢分享) - 独立工作时，你做什么（开发独立工作，写代码；ScrumMaster呢） - 交付是什么（开发的交付是产品增量；ScrumMaster呢） 如果你已经可以很好的回答如上两个问题。恭喜你！已经上路了。 如果你还不知道答案，那么我们来梳理一下： ScrumMaster的技能要求： Training（培训） Mentoring（师傅） Facilitating（引导） Coaching（教练） 培训 作为一名ScrumMaster，需要具备基本的培训技能。培训技能，我个人理解至少有2个阶段。 第一阶段，演讲 – 敢于在陌生人面前进行分享。同时还要是逻辑清晰，有理有据，能说服人。训练自己的演讲和领导能力，可以参考 Toastmasters 第二阶段，培训方式 – 常见的培训、分享方式是，整理ppt，对着电脑进行分享。还有一种培训手法叫做《Training from the Back of Room》，即最大限度的使每个学员从彼此学习到新的知识。这本书中文名《4C法颠覆培训课堂：65种反转培训策略》 师傅 每个人都可以成为师傅，也需要有自己的师傅。这个都是需要造化。 引导 团队会议的高效，取决于主持人的能力（即引导能力）。市面已经有很多的培训和书籍，大家可以自行查找。推荐引导书籍： - 《引导》 - 《从困境走向成功》 - 《专业引导技巧》 - 《引导工具箱》 教练 教练，就是一面镜子。教练可以反映出团队的现状。也有很多教练流派，方式方法。这里不做一一列举，具体可以参考 ICF（国际教练联盟） 思考 ScrumMaster是一个全新的职位，他不做实际的开发工作，他的工作重点是团队、组织。ScrumMaster的工具和开发不同，有许多的工具箱。 你想要了解ScrumMaster工具箱吗？可以回复邮件或提交issue。 每日问题 你对ScrumMaster是如何理解的，又是如何做的？欢迎分享。 欢迎加入自由职业者俱乐部 微信群，请加微信： baobaotalk_com ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang
2019/4/20
articleCard.readMore如何构建信任
如何构建信任 每个人都希望获得信任，团队和组织也希望获得他人的信任。 这里有HBS（哈佛商业学院）的教授分享，她在Uber如何构建公司形象，获得信任的。 信任是一个ALE三角（如下） Authentic（正直） Logic（逻辑） Empathy（同理心） 同理心 同理心是最容易松动，也较容易修复。 如果一个人没有同理心，那么他是很难获得信任的。 只有同理心，才能获得信任。 逻辑 获取信任的第二个要点是要有逻辑性。 讲话讲重点，不要绕弯到最后都没有点明主题。 正直 这个是最难修复的。就是一个人是否正直。 只有正直的人，（总不能人前人后不一样吧）才能更容易获得信任。 思考 获取他人信任这块，我认为正直是第一位的，逻辑是第二位，同理心是第三位。 正直是根本。 每日问题 你在获得他人信任方面，有什么体会和心得，欢迎你的分享。 欢迎加入我有一个梦想 - 自由职业者俱乐部 微信群，请加微信： baobaotalk_com ； 添加微信后，发送消息 dream 广告时间 订阅邮件列表 - 我有一个梦想 和BoB面对面学习Scrum 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者
2019/4/19
articleCard.readMore改善倾听的5种方式
改善倾听的5个方式 来自TED视频的一个分享，如何改善倾听： silence 安静 mixer 混合器 savoring 品味声音 倾听的状态 RASA (精华) Receive, Appreciate, Summarise, Ask 安静 只有静下来，才能听到很多声音。不信你可以屏住呼吸，仔细的听一下周围的声音。 混合器 现在的都市里充斥着大量的声音，学习从这些声音中分别出不同的声音。比如哪些是小桥车，哪些是大卡车，哪些是公交车的声音。 学会从混合的声音中分别出不同。 品味声音 如洗衣机的声音，像和弦；飞机起飞的声音像………… 倾听的状态 要练就一个倾听的状态，时刻都要注意倾听。 RASA 有关倾听最后的总结，用RASA来总结的。 收到。倾听第一步要收到。 欣赏，赞赏。要有一颗感恩的心。 总结。用简短的话总结对方的描述。 提问。对于对方的描述有问题，马上提出疑问。 思考 和别人沟通时，你处于倾听的状态了吗？ 别人说话的时候，你看手机了吗？走神了吗？有没有漏掉重要信息？ 每日问题 尝试着认真倾听一个人说话，看看是什么感受？欢迎和我分享。 欢迎加入我有一个梦想 - 自由职业者俱乐部 微信群，请加微信： baobaotalk_com ； 添加微信后，发送消息 dream 广告时间 订阅邮件列表 - 我有一个梦想 和BoB面对面学习Scrum 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer）
2019/4/18
articleCard.readMore有效练习
有效练习 《异类》书中提过10000小时理论，即某一领域想要出类拔萃，需要持续练习10000小时。 需要持续练习是肯定的，但是否10000小时，我持有保留意见。 比如练习马拉松、练习游泳、练习弹吉他，每一项技能所需要的时间都不相同。 有的技能用不上10000小时，有的或许10000小时还不够。 10000小时什么概念？ 假设每天练习8小时，那么需要1250天，即3.4年（这是没有节假日休息的情况下）。 那有没有方法进行有效的练习，技能快速提升呢？ 答案是肯定的。 想要进行有效的练习，这里有2个方法： 切断打扰 高质量反馈 切断打扰 有数据表明，现在职场中的人不被打断的时间是6分钟。也就是说只能持续工作6分钟，然后就会被微信、邮件、提醒等打断。 我们要做的第一步就是切断这些干扰。 如关闭手机的通知（可以切换到飞行模式），关闭邮件以及其他不相干的网页。 高质量反馈 练习后反馈是必须的，如自我反思（回顾）。 还可以对自己的练习进行录像，查看回放。 也欢迎你对我的每日写进行反馈，反馈方式可以是邮件或提交issue 思考 今天提到的是有效练习，其实针对工作中的任何事情，想要做到高效，一定需要自我独立思考工作的时间。 每日问题 回顾一个你的特长，你是如何进行有效练习的？ 欢迎加入我有一个梦想 - 自由职业者俱乐部 微信群，请加微信： baobaotalk_com ； 添加微信后，发送消息 dream 广告时间 订阅邮件列表 - 我有一个梦想 和BoB面对面学习Scrum 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者
2019/4/17
articleCard.readMore苦逼模式和甜点模式
苦逼模式和甜点模式 苦逼模式 截止日期是有效的。 这个（截止日期）有效是因为人们专注于思想并创造紧迫感。 截止日期会让我们提交税款或完成任务。 截止日期是我们必须做的工作的外部杠杆。 甜点模式 另一方面，甜点也有效。 吃完所有蔬菜后，您不需要外力来鼓励您吃甜点。 这是你要做的事情，而不是你必须做的事情。 您可以围绕截止日期来建立工作生活。 你可以拖延，支付最后的罚款并推迟最后一分钟的紧急情况， 因为你需要所有这些才能进入“苦逼（必须）”模式。 或者，您可以沿着您认识的最富有成效和快乐的人的道路前进。 通过重新定义您选择做的工作，就像您要做的那样（甜点模式）。 是的，我会指出你甚至可以用税收做到这一点。 这是你要做的事情，因为你成功并且幸运地生活在一个公民社会中。 Deadlines work. They work because they focus the mind and create urgency. They work to get us to file our taxes or finish an assignment. They’re an external lever for the work we have to do. On the other hand, dessert works too. You don’t need an external force to encourage you to eat dessert after you’ve finished all your vegetables.
2019/4/16
articleCard.readMore无印良品
说一说无印良品 无印良品，是指“没有名字的优良商品”。 – 维基百科的介绍 公司的三大理念： - 精选材料 - 修改工序 - 简化包装 一个无印良品的故事 没有名字也是可以作为品牌，无印良品做到了。 今天和一个朋友聊到韩国食品，看到一个品牌名字No Brand。 现在这样没有名字和没有品牌，都是可以作为你的品牌。 这是产品的品牌。 在当前的互联网时代，对于个人而言是最好的一个时代。 每个人都可以有自己的品牌。（个人品牌） 如何打造个人品牌 今天微信群的一个朋友问到： 现在每个人工作都那么忙，一天就在自己的一亩三分地，怎么拓展有效交友圈呢？ 针对这个问题，我有一些发言权的。我的做法如下： 自己持续输出，总结。别人看到了，自然会关注你，联系你 去参加线下活动，不建议大会，可以是10-20人小的活动。大家能互相交流的那种 所以，持续输出吧，哪怕像我写的这么差的。 思考 （移动）互联网时代，每个人都有自己的品牌（或者说你在别人眼中的人设）。 你的一举一动，每一句话都在为你塑造品牌。 比如我的品牌标签： 敏捷、Scrum培训师、Scrum联盟、社区、开源、区块链 每日问题 你的个人品牌标签是什么？ 欢迎加入我有一个梦想 - 自由职业者俱乐部 微信群，请加微信： baobaotalk_com ； 添加微信后，发送消息 dream 广告时间 订阅邮件列表 - 我有一个梦想 和BoB面对面学习Scrum 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer）
2019/4/15
articleCard.readMore士兵思维和侦察兵思维
士兵思维和侦察兵思维 士兵思维 士兵思维模式是指有些信息和想法就像是我们的盟友，我们希望它们能赢，我们会尽力保护它们。还有些信息和想法感觉就像是敌人，我们就想要打垮它们。 举个例子，当你在看足球比赛的时候，其中一个球队是你最喜欢的球队。当裁判判罚你喜欢球队犯规时，大脑的第一反应是，这个SB裁判，判罚过重。而如果判罚对手犯规时，大脑第一反应是判罚正确，就是犯规，没任何问题。 – 这就是士兵思维 我们都会试图找到对自己有利的证据，试图证明它是正确的。这也叫确认偏见（confirmation bias）。 侦察兵思维 侦察兵思维模式则意味着能够摒除自己内心的歧视(prejudices)、偏见(biases)和倾向(motivations)，尽可能尝试着客观地找出事实和证据。 举个例子，当我们做某个话题研究时，早期更多采用的是侦察兵思维。即收集更多的信息、事实，而尽可能不做判断，抛弃一些反面观点、过激想法等。 这两种思维方式来自于 Julia Galef 的演讲，如下： Why you think you’re right TED 两种思维的对比 在TED视频中，Julia举了一个19世纪法国军官的例子。当大家认定某个人是间谍时，就会竭尽全力找证据证明他就是间谍，最后冤枉了好人。而其中有一个军官，他觉得哪里不对，花了10年的时间找出很多证据证明了被冤枉的人，是清白的。 显然地，侦察兵思维会开拓我们的视野，有助于我们提升判断的质量。那么如何培养侦察兵思维，Julia给出了三个建议： Curious - 好奇心 Open - 开放 Grounded - 看重事实 最后，Julia给出了一个终极大招，激发人们的想象力。她引用了《小王子》作者 圣埃克苏佩里 的一句话： 如果你想造一艘船，不要雇人去收集木头，不要发号施令，也不要分配任务。而是去激发他们对海洋的渴望。 – 圣埃克苏佩里 下面附上原文： 侦察兵思维，当我们感觉到自己错了的时候，要引以为豪而不是羞愧；要提出来，而不是尝试隐藏。 如果遇到信息与我们的信仰冲突时，学会好奇而不是抵触。 思考 侦察兵思维，一个非常棒的隐喻，开拓了我的思维模式。 其实更像是 critical thinking。 每日问题 今天的问题是： - 你有没有遇到过士兵思维模式，你是如何跳出这种思维模式的？ 广告时间 订阅邮件列表 - 我有一个梦想 和BoB面对面学习Scrum 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/4/13
articleCard.readMore为什么做正确的事情这么难
做正确的事情为什么这么难 Do Right Things vs. Do Things Right 多么正确的一句干货、真理、理论。但为什么总是很少数的人可以做得到？是很难，还是走错了路，亦或是其他什么原因？ 前天和一位多年的好朋友聊天，发现他在做很多的事情，但在每个领域都没能达到一个顶尖位置。（如培训、咨询、工程实践等） 貌似这个也是大多数人的困扰，有关如何快速学习一个领域，我有过一次分享，中间有部分提到这个内容。 在快速学习了解一个领域后，接下来就是要锚定一个目标（为之奋斗的7年目标）。在很长一段时间里，达到该领域的Top3的位置。 这个是我的 T 型策略 – 优先在一个领域做到顶尖，即T的竖。然后再横向扩充知识领域，即T的横。 为什么好多人没能做到 一个原因就是多数人并没有找到为之奋斗的目标。 另一个原因是找到目标后，没有能持之以恒。 如何找到奋斗的目标 奋斗的目标，这个会因人而异。有的人目标远大，如Elon Musk要把人类送上火星。而有的人目标很实在，比如我的目标是一年赚一个小目标。那这个目标要怎么找，我个人经验是，用力的思考。有时间就想一下，我到底要什么？ 为人类服务是第一位 还是赚钱是第一位 还是家庭是第一位 总有一个第一位顺序的事情，也总会有一个排序。每个人有自己的顺序清单（你应该要有，后面我会专门写一篇关于清单的文章） 在遇到问题的时候，根据自己的顺序清单进行选择就会很简单。 所以说你的目标是什么，已经写好在清单上了。 找到目标后，不能持之以恒 恭喜你，如果你已经找到了目标。接下来就是需要持久的去做，去实现你的目标。 从上面不难看出，一般来讲，目标是比较远期的、比较大的事情。如果说下一步做什么，往往还是很困惑。 其实下一步行动，这是一个任务拆解的过程。 比如我的目标是成为一名 Certified Scrum Trainer，那么我就会去了解什么是CST，以及它有什么要求。详情点击这里 了解这些信息后，就能看到有很多具体的要求，如： 完成个人声明 准备课件和学习目标的映射 培训记录 培训反馈 其他讲师的推荐 等等 每一项都可以拆解出更加细化的多个任务。 是不是清晰一些了呢？ 思考 每个人都有自己认为正确的事情，但那真的是正确的吗？ 可以把自己的想法，多和朋友交流一下，说不定有新的发现。 这篇文章，也是我和朋友聊天后的一些思考，一些发现，希望能对小伙伴有帮助。 每日问题 今天的问题是： 你的(人生)7年目标是什么？ 广告时间 订阅邮件列表 - 我有一个梦想 和BoB面对面学习Scrum 版权声明 本文采用 CC BY-NC-SA 3.
2019/4/11
articleCard.readMore如何验证信息的真伪
如何验证消息的真伪 – 记微信群讨论“硫柳汞”副作用 故事起源于，在我们的一个程序员爸爸群中，有人抛出一个话题： 不管进口(疫苗)的还是国产的都含有大量的汞和银作为辅助剂，是远远超标的。…… 此消息一出，群里炸了。（都是有娃娃的爸爸呀） 第一批消息，大家想知道信息的来源（有没有来源）。接着想知道这里说的汞到底是什么。 得到的回答是硫柳汞 后续是一系列互动、讨论。 重要的几个观点如下： - 疫苗是收益大于风险 - 没有最好最坏的，都是平衡的结果 - 反疫苗是人类的灾难 - 毒性必谈剂量，离开剂量就是耍流氓 那谈到这么多后，就必须要求证一下信息来源了。（抛出话题的人并没有提供信息来源） 演进的态度， 通过搜索引擎查询关键词 硫柳汞 疫苗 副作用 百度的结果如下： 不敢看呀，看完这些消息后，真的不敢打疫苗了。。。 只有第七条简书那一条中才提到一些理性的分析。 本着严谨的态度，我们再用谷歌查一下，结果如下： 其中第一条新华网就是辟谣新闻，第二条到第四条都是世界卫生组织的结果。 群里有人贴出第二条结果的答案，讨论才算告一段落。 硫柳汞和疫苗 1999年，美国对暴露于疫苗中汞的问题表示了关注。这是基于认识到按照婴儿免疫程序，累积的汞含量可能超过美国政府的一个机构所推荐的甲基汞的允许值。但是，硫柳汞作为一些疫苗的防腐剂，所含并非甲基汞而是乙基汞。全球疫苗安全咨询委员会（GACVS）在2000年8月的一次特别会议上第一次评估了含硫柳汞疫苗的安全性问题，并在之后有新证据出现时就该议题继续进行审评。GACVS最近一次会议（2006年6月5-7日）重申以前的结论，即没有证据表明疫苗中的硫柳汞对受其暴露的婴儿、儿童或成人具有毒性。 参考链接 思考 从微信群里这个消息的讨论，我们可以学习到： - 不轻信 - 用谷歌 - 查权威 不要轻易相信别人转发的消息，尤其在这个自媒体繁(hun)荣(luan)的时期。消息真的是满天飞，都是想尽一切办法来吸引眼球的。 搜索引擎，还是用谷歌。尤其在搜索专业知识的时候，如本例、或者很多软件开发相关的问题。 最后，遇到问题，尽可能找知识的源头。比如软件开发框架遇到问题，先查官网，官方api，等等。 每日问题 你身边还遇到过哪些谣言？ 你是用什么方法识别的？ 欢迎通过 提交issue 留言， 或者邮件讨论 bob at c4at.cn 广告时间 订阅邮件列表 - 我有一个梦想 和BoB面对面学习Scrum 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。
2019/4/10
articleCard.readMore干货与实践
干货和实践 干货(理论)和实践 什么是干货 干货，又名理论，干干的理论。怎么说都是对的，可以放到很多场景里。 比如 Plan is nothing, planning is everything. 这句话是来自美国上将，艾森豪威尔将军。这句话就被无数的讲师、咨询师挂在嘴边上。 很多人仅仅理解为：计划无用，规划是一切。 可是除了这个意思，有没有更深层次的理解，亦或是可以用到什么场景下？ 实践出真知 有了理论（干货）之后，需要把干货能放到具体的场景下，得到验证，才是有用的干货。如果只是知道一个干货理论，又如何？ 身边也有一些朋友，是实干家。敢于做任何尝试，不一定理论知识有多么丰富，但是实战经验很高。 就好比创业是个实践（实战）的过程，不是靠着一本精益创业就能走遍天下。 敏捷也是个实践过程，不能仅靠敏捷宣言（和原则）的理论行走天下。（这是老司机的做法） 我相信还有很多的行业都是遵循这样的原则（实践出真知）。 所以不要盲目相信干货（理论），缺乏了实践（上下文）的干货没有任何价值。 版权声明 本文采用 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中文文档
2019/4/9
articleCard.readMore暴徒式编程简介
暴徒式编程 Mob Programming 什么是暴徒式编程 暴徒式编程(Mob Programming)是一种软件开发方法： - 整个团队一起工作于同一件事情 - 在相同的时间 - 同一个地方 - 用同一台电脑 暴徒式编程和结对编程类似（结对编程指的是两个人坐在一个电脑前，同时工作于同一段代码）。而暴徒式编程做得更加极致，团队里的每个人用一台电脑来一起写代码。 除了写代码，团队在一起完成软件开发几乎所有的工作，诸如定义故事、设计、测试、部署、澄清需求等等。几乎所有这些工作之前都需要工作会议或工作坊。我们每天都是如此工作。 暴徒式编程，比极限编程还要极限（尤其是说结对编程）。它将软件开发推向极致。 具体的操作，大家可以参考如下链接： 参考链接 我正在邀请 Woody 来中国，如果你对这个话题感兴趣，欢迎报名Woody的工作坊。 为什么 Woody 他们会用暴徒式编程 答案非常简单。这个是团队的决定。有一个非常重要的概念，由团队来决定如何完成他们的工作，而不是被指派。团队可以持续改进、优化工作方法。 为什么暴徒式编程有用 我经常在课程上问学员这样一个问题： 软件开发的目的是什么？ 大家在继续阅读之前，不妨也思考一下这个问题。软件开发的目的是什么？ 我给出的答案是（答案并不唯一）： 软件开发是为了解决客户问题。 既然是解决客户问题，那么就需要很多的互动、需求澄清。而不能指望说，需求固定下来。（因为脑子里面的想法总是在变化的） 那在理解需求，澄清需求，设计，架构，写代码的过程中，就需要很多的互动。 早在2001年敏捷宣言提出时，就写到 个体与互动 高于 流程与工具 （不能单单看高于，要看上下文） 如何把互动做到极致，暴徒式编程这个方法就做到了极致。 对于软件开发而言，大部分的时间用于 - 开会 - 澄清需求，讨论需求 - 设计 - 代码评审 - bug - 重写代码 等等 而暴徒式编程的过程中，就已经包含了上述的大部分过程。 对这个话题及课程有兴趣吗？ 可以给我发个邮件进行盲鸟报名（极低的占坑价格） bob at c4at.cn 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang
2019/4/8
articleCard.readMoreAgile and Blockchain
Agile and Blockchain The origin Many say blockchain is just a decentralized ledger, it is true, but not the essential part for blockchain. I (BoB) as an experienced agile guru (Certified Scrum Trainer from scrumalliance.org), would anatomize blockchain with you together and compare agile and blockchain, and try to find the fundamental for both. In the beginning, let’s start from the history to understand how they come. what is agile In 2001, there are 17 software pioneers gathering in snowbird to discuss the light software development methods.
2019/4/6
articleCard.readMoreBob的敏捷之路
Bob的敏捷之路 本文是我在2019年3月23日杭州敏捷组织者聚会上的分享。主要包含以下内容： 敏捷教练需要什么技能 如何快速进入一个行业 个人学习工具推荐 敏捷教练需要什么技能 根据 Lyssa Adkins 的《Coaching Agile Team》这本书，参照下图敏捷教练需要以下技能： - Teaching - Facilitation - Mentoring - Personal Coaching 除了敏捷、精益知识的深度之外（本文不提这个方向，默认已经具备），还需要具备以上4项软技能。从我自身的经验来看，我着重于前两项技能，即 Teaching, Facilitation。 Teaching 教学(Teaching)，其实有很多的方式。我从最基础的演讲技能开始锻炼的。早在2011年我加入了 Toastmasters，（中文叫土马演讲俱乐部，其实这里远远超出了演讲的。）在土马3年多的时间里，我的演讲能力及提意见的能力都得到了很大的提升。另外还有领导力也得到了锻炼。所以我是非常建议小伙伴找一下你身边的土马俱乐部，去试一试。 Facilitation 引导是另外一个我重点关注过的领域，去学习过几个很棒的课程。比如行动学习、引导的秘诀、欣赏式探询等。另外还有一些介绍引导工具很棒的书籍，如《引导》、《引导者工具箱》、《Game Storming》等 个人发展 个人发展有两个维度的思考： 发展方向 如何用好自己的爱好 发展方向 请用心回答3个问题： 1. 未来7年你想成为一个什么样子的人？ 2. 你现在的技能和优势是什么？ 3. 可以采取哪些方式方法？ 作为个人，可以通过3种方式来赚钱： 1. 卖自己的时间 - 如我现在的 CSM/CSPO/CLB。 2. 可以重复的卖自己的时间 - 如我和伙伴在做的HiBlock区块链的培训。 3. 可以用别人的时间来赚钱 - 如合作或成立公司等。 如何用好自己的爱好 用自己的爱好构建一个社区，并用工具沉淀相同爱好的伙伴。相信我，你会有意外的发现。 如何快速进入一个行业 进入一个行业的时候，往往会比较迷茫。比如一个Scrum新人，或者Tensor Flow新人，一开始并不知道学习什么，从哪里入手。我的经验是，先找一下这个行业中最权威的认证是什么，以及该认证体系中最高的认证的标准是什么。这个标准是这个行业顶尖专家汇总的结果。用这个标准作为行动的清单，检查自己有哪些缺少的地方。可以很快的搞起来。 比如Scrum领域的权威认证就是 Certified Scrum Master，该体系中最高的认证就是 Certified Scrum Trainer (CST)。我现在是一名CST，致力于在中国推广Scrum。
2019/4/6
articleCard.readMore一生的选择
一生的选择 人的一生其实有很多很多的选择，或者用另一个说法，人的一生是选择组成的。 每一次的选择就代表我们走入了一个新的路程。 不过人的一生中确实有几次重大的选择： 大学 工作 婚姻 大学 一所好的大学，不仅仅是名气，更多的是你所能链接到的人脉和资源。可惜了我自己就没有能上一所好大学。第一次选择不算很成功。 工作 工作是第二次重大的选择。如果你的工作是你最喜爱的事情，恭喜你。如果你的工作是你不得不做出的选择，那么可以考虑一下自己最喜欢的事情是什么，愿意为之付出一生的事情是什么。 我愿意付出一生的事情是，培训、社区及连接人。 婚姻 婚姻大事，这个不好多说。每个人都知道重要，但不一定能做好选择。寻找什么样的伴侣，也决定了你的半生。 人生除了以上的三大重要选择，其实每天都在充满各种选择。 比如，这个客户是否要接，明天中午吃什么，要不要选择创业，等等 那么做出选择的依据是什么，每个人都不同。 其中最重要的是，个人目标（或者说个人的价值观），即终极目标，你想要什么样的生活？ 确定好目标之后，一切选择就不会那么纠结。 比如我刚刚选择取消了澳大利亚的行程，因为我的目标是家庭和睦。 好了，到这里，每个人都可以认真思考一下，你的人生目标是什么？ 版权声明 本文采用 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中文文档
2019/4/6
articleCard.readMore打造技术社区123
打造技术社区123 在开始讨论打造技术社区之前，先要搞清楚为什么打造技术社区，即明确目标（Why）。 为什么打造技术社区 打造技术社区的目的，我经历过的有三种： 1. 纯粹的兴趣爱好 - （同时发起者有着一腔热血，哦不，是热情） 2. 商业（业务）的拓展需要 3. 目的不纯 - 混合了兴趣和商业的目的 纯粹 如何打造技术社区 第一步 - 选择方向 打造技术社区的第一步就是选择方向。这个方向不能太宽泛，也不能太窄。什么样的方向比较合适呢？举个例子： Ruby社区，如Ruby China 以太坊爱好者 等等。不合适的例子，如CSDN，这已经不是一个社区。 第二步 - 持续打造内容 打造内容也有多种方式，常见的有两种： 一种方式是编辑（专家）写专业内容。比如技术媒体。 另一种方式是用户创造内容（UGC）。 两种方式各有利弊。对于纯粹兴趣爱好的社区，第二种方式会很多见。 第三步 - 定期举办技术沙龙 定期举办的技术沙龙，是社区凝聚力非常好的方式。可以分为线上分享和线下分享。想要办好一次技术沙龙，也有很多的注意点。(有兴趣的可以私下聊) 第四步 - 举办技术会议（可选） 技术会议(一般是100人以上)是一种很划算的社区活动。 社区到底是什么 社区是一群客观上相互联系的团体或网络能够彼此产生相对持久的社会关系，除了超越眼前的家庭关系之外，且彼此能够定义出关联作为他们社会身份和社会实践的重要事项。 – 引用自 维基百科上的社区的定义 一般而言，社区里的人拥有共同的价值观或文化。互联网诞生后，社区的发展更加蓬勃。网络上的各种兴趣爱好社区层出不穷。 我亲身经历的社区有： 敏捷社区 HiBlock区块链技术社区 那么社区从本质上来讲，就像一个集市，人群来来往往。有需求的人自然会选择加入，强烈需求就可能会加入组织者，一起贡献力量。作为发起人，更多需要考虑的是如何组织好社区。 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区（hiblock.
2019/4/6
articleCard.readMore杭州敏捷之旅组织者聚会（2019）
杭州敏捷之旅组织者聚会（2019） Bob的分享（待整理） 胡键的分享： 一个知识点，公司的招聘条件会随着公司的发展，而进化。 有意思的发现： - 创业公司，能搞定事情第一位 - 大公司，填好坑 优秀的ScrumMaster（杨明） 从不同的视角（管理者、团队成员、ScrumMaster自身）来定义： - ScrumMaster有哪些特点 - 隐喻（画） 组织者聚会，唯一的决策： 2020年在西安聚会 创建敏捷之旅的github组织 希望可以借此，开始协调起来。 版权声明 本文采用 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中文文档
2019/4/6
articleCard.readMore西安奔驰事件我的想法
西安奔驰事件我的想法 西安奔驰漏油-腾讯新闻 尝试厘清一下事实： 女子购买奔驰 开出去5分钟，发现漏油 返回店里，寻求解决方案，15天后 4S店只同意按照国家三包政策，换发动机 上述最后4S店同意按照国家三包政策执行，表明一个事实：汽车质量存在问题 那么在买车几分钟内（已经签单交钱），出现的质量问题，应该如何界定已经不重要，重要的是如何解决问题。 如果我是当事人，我会先梳理我想得到的结果： 退款 换车 这个质量问题，我不会买单（无论是商家还是厂家的问题） 然后梳理干系人，对于出现的这个问题，商家的痛点在哪里，为什么不肯换车？ 新闻得知女子的处理办法是： - 和商家（4S）协商 - 工商局投诉（很不幸，不作为） - 媒体 那么除了上述方法，有没有其他的方法，首先得梳理西安利之星的干系人： - 利之星的总部 - 奔驰中国（或奔驰总部） 所以我的处理办法，可能还会尝试如下： - 联络利之星总部 - 联络奔驰中国（或奔驰总部），这个是源头 思考 遇到问题多思考，以终为始，先想清楚自己想要的结果是什么（最好是多选）。 想清楚结果后，梳理问题的干系人有哪些。（如本例中，官、商 两个角度） 针对不同的干系人，可能会采用不同的方式。 每日问题 平时的工作或生活当中，你遇到过哪些糟心事？ 你是如何解决的？ 广告时间 订阅邮件列表 - 我有一个梦想 和BoB面对面学习Scrum 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人
2019/4/6
articleCard.readMore为什么开发者不关心敏捷
日期：2019年3月27日 今天和朋友聊天的时候，提到了一个问题（也是我在CSM敏捷认证课程中碰到的问题）。 通常我会在课程上做几个简单的调查： 有多少人是开发者？ – 不会超过1/3 有多少人看过敏捷宣言？ – 令人惊讶，比例低到吓人 尽管有很多学员说我们已经在实践敏捷（其实他们的原话是，在推敏捷），但没有看过敏捷宣言。这个着实让我意外。 和朋友一起分析了一下，为什么开发者不会关心敏捷。原因如下： 刚入职场的开发者，焦点在如何快速提升技术能力上，如 python, react, vue 等 大概3-5年的开发者，至少都是开发组长（team leader）。这个时间点最应该来看一下敏捷，但是这个时候也是这个人最忙、最挑战的时刻。天天忙到焦头烂额，到处擦屁股，开会………… 提升到管理者之后，身背绩效指标，就一个目的，完成绩效是第一位，其他都要让步。（所以短期目标和长期目标之间，一直在选择短期目标，没有时间选择长期目标） 所以综上，敏捷是作为一名开发者最应该了解学习的技能，它完全可以融入到日常工作中去。 如果你是开发者，你了解过敏捷吗？ 你认为敏捷是什么，你工作中有哪些地方用了敏捷？对你的工作帮助大吗？ 如果有问题，欢迎大家通过issue进行讨论 版权声明 本文采用 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中文文档
2019/4/6
articleCard.readMore京东敏捷软件开发套路
京东敏捷软件开发套路 ##开场语 京东，作为国内最大的电子商务公司，是如何进行敏捷转型的呢？在转型过程中，都碰到过哪些坑，然后又用了哪些套路，得到了什么样的结果。 我将结合自己在京东进行敏捷转型的实践，告诉大家：敏捷的核心是什么？如何进行敏捷团队转型？团队转型需要注意什么？ ##背景 京东到家，2014年作为京东一个内部项目，在移动互联网的大浪潮下从一开始就注定了不平凡。京东在2015年重点打造的战略级项目，其中就包含京东到家，即基于京东强大的物流体系，整合各类O2O（线上线下）服务，主要以提供生鲜和超市产品为主。 这次分享中，我主要会介绍在2016年中，给京东到家其中一个20+的团队进行敏捷转型的案例。这个团队主要是负责京东到家的商家入驻后台，内部会和京东到家的各个团队，如业务团队、app团队、结算团队等有交集，外部与京东（包含但不限于法务、财务、审计等团队）、入驻商家、入驻商家IT团队等对接。 ##如何转型 前面简单介绍了这个团队的背景，那么这个团队的转型中我们都做了什么，为什么要做这些事情呢。下面和大家一一进行拆解。 ###前提 取得信任，达成一致。 取得信任。在团队进行转型之前，一定需要得到所在团队经理或总监的认可与支持。这里的支持不是说口头说，我支持敏捷转型。而是真的会付诸行动。比如经理自身管理风格的转变，做事方法的变化等。 达成一致。达成一致需要多个层面都能统一认识。比如敏捷转型的阶段成果，比如团队的度量。一般阶段成果以3个月（季度）为单位呈现，其中每月有汇总演示。 ####度量（绩效管理） 达成一致的一个体现就是度量。下面稍微展开说一些关于敏捷度量的事情。更多的信息可以参考吴穹的“研发组织该如何设计绩效体系” 绩效管理的目标 提高个人业绩表现 改善组织结果 决定加薪或升职 1. 提高个人业绩表现 绩效管理的目标之一就是帮助个人提高，或者换个说法，个人在公司里工作的主要动力之一也是可以自我学习、提升个人价值。 反观大部分公司的绩效管理是如何做的呢？ 多数公司都是等到了年底的时候，直接经理进行一次性的打分（针对这一年的表现），然后根据这样的打分来决定个人一年的总体表现。这样做，对于提高个人表现有多大的帮助呢？总之，我认为作用不会很大。 2. 改善组织结果 很多组织会有一大堆考核组织（或者团队）的度量指标——多的甚至达到20+。这么多的指标究竟有哪些可以指导组织（或团队）的改进，有哪些有负面作用？ 另外，这些考核组织（或者团队）的指标往往掌握在管理者手里（团队成员并不知道）。那么这样的绩效管理对于改善组织结果的作用有多大，是值得商榷的。 3. 用于加薪或升职 正如绩效管理第一个目标（提高个人绩效）中提到的，多数公司是每年（好一点的是半年）做一次绩效评估，然后根据这次评估的结果来决定一个人的加薪或者升迁。这样的话就会导致评估结果不能真实反映实际情况，举个例子，某员工小明，在11月底的代码提交中引出一次线上事故，而在前10个月中小明表现都非常优秀。在这个情况下，小明这一年的绩效评估结果会怎么样？很不幸，估计不会太好。原因如下：1. 尽管小明之前表现非常优秀，但这次犯了错误。2. 尤为关键的是这个错误恰好在绩效评估之前，管理者记忆犹新。 前面我们列举了绩效管理的目标，以及传统按年进行绩效评估的缺陷。那么在敏捷软件开发中，如何进行绩效管理呢？ 度量指标的分类 在谈及绩效管理度量指标之前，我先对度量指标做一个粗略的分类。度量指标可以分为： 内部度量指标 外部度量指标 内部度量指标 内部度量指标，指的是度量组织（或团队）内部的指标（从内部看）。举个例子，比如个人或者团队的代码行数，单元测试覆盖率，缺陷数等等。 内部度量指标主要用于提高组织（团队或个人）的效率。 外部度量指标 外部度量指标，指的是度量组织（或团队）外部表现的指标（从外部看）。举个例子，比如ROI，客户满意度，NPS等。 外部指标主要用于指导组织（团队或个人）的方向，从而组织盈利或获得成功。 敏捷软件开发的度量指标 选择度量指标的时候，有几个因素需要着重考虑： 公司的目标是什么，这个度量指标和公司目标匹配吗？ 组织（或团队）的改进方向或重点是什么？ 这个目标的数据收集工作有多大？更新周期是多久？ 最后，针对绩效管理度量，还有两个重要原则： 结果比过程重要 学习比失败重要 ###推与拉 取得信任并达成一致后，还需要考虑的问题就是推敏捷，还是拉敏捷。 推敏捷指的是推广敏捷，即团队没有真正的动力去进行组织转型而是被推着走。比如听说敏捷能提高效率，听说敏捷能解决软件开发的很多问题，等等。这种情况下进行敏捷转型，结果多半是不理想的。 拉敏捷指的是团队有意愿进行敏捷转型（内驱力），而不是上述的推。 上面分析的是敏捷转型前判断团队的状态，是推还是拉。
2019/4/6
articleCard.readMore什么是系统思维
什么是系统思维 系统思维（system thinking），也叫系统思考、系统动力学，是一种用整体思维来思考问题的方式。 系统思维的来源 如果从整体思维的视角来看，中国古代的道家思想，是比较早的系统思维方式了。 现代的系统思维更多指的是麻省理工学院（MIT）的系统动力学（System Dynamics）。 系统思维在彼得圣吉的《第五项修炼》中被作为五项修炼中的一项而提出，后来广为流传。 在LeSS（大规模敏捷）中，也有针对于系统思维的介绍。（LeSS十大原则之一，也是非常重要的一条原则。） 系统动力学（系统思维）内容 在系统动力学中，有很多内容。很详细很丰富，在麻省理工学院是有专业课程，也可以用来分析很复杂的问题。 常见的内容如下： 行为趋势图（Behavior Over Time） 环路图（Casual Loop Diagram） 存量流量图（Stock Flow Diagram） 行为趋势图 行为趋势图，是观察某个行为在一段时间内的变化趋势。这个趋势可能是： - 随着时间，趋势趋于平稳。（稳定在某个水平上）可能存在平衡回路 - 随着时间，趋势越来越陡峭。可能存在增强回路 - 随着时间，趋势呈现波浪形（即上下波动）。可能无规律 环路图 环路图（简称CLD）是系统动力学中的一个重要工具。可以用来分析系统中的复杂动态关系。但请注意，不要仅仅为了画图而去画CLD，这个画图的过程也是非常关键，即团队在共享知识而达成一致。 环路图有两种： - 增强回路（Reinforce Loop），常用R表示 - 平衡回路（Balance Loop），常用B表示 环路中还存在： 变量（表示变化的元素） 链路（表示变量之间的因果关系），链路存在两种关系： 正相关（正反馈），常用+或者S表示 负相关（负反馈），常用-或者O表示 存量流量图（SFD） 存量流量图（SFD）是系统动力学中另一个很重要的工具。它是在CLD的基础上，增加了系统中量的变化观察。比如有的变量对于系统的影响很小，而有的变量变化是至关重要的。 这里面具体体现就是，有的变量是存量，而有的变量是流量。存量的含义是说，这个变量是总数（积累量）。比如中国人口总数，这个变量就是存量。而流量指的是变量的流动，如中国每年移民美国的人口数。 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区（hiblock.net）发起人 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人
2019/4/6
articleCard.readMore开源软件的盈利模式思考
最近一年我进入了区块链行业，和伙伴们一起在运营区块链技术社区，即 hiblock.net。在这个过程中，对我影响最大的是接触到很多开源社区的伙伴。从而让我对于开源有了更多的认识。 开源软件 首先明确一下开源软件，不代表免费，不代表开发者就是义务贡献。开源软件这个名词最早来源于自由软件（Free Software），由于Free这个词在英语中有免费的含义，后来人们就用了开源软件（open source software）。 而对于自由软件，Richard Stallman终生都在进行推广。自由软件的含义远远超过开源软件的定义。 什么是开源软件wiki 什么是自由软件wiki 开源软件的商业模式 个人总结的开源软件，有4种商业模式： 插件付费 云服务收费 咨询费 基金会 插件付费 项目主体（大部分）是开源的，社区都可以贡献（提交issue，修复bug等），并遵循某个开源协议。（如MIT，Apache等）而该项目所依赖的插件是付费的。插件的付费可以是订阅模式，或一次性付费模式。 该类型常见的项目有：Hadoop, VS Code, (欢迎大家补充更多的例子) 云服务收费 我一直对于大公司开源有个疑惑（如阿里，腾讯，华为的开源），不清楚他们为什么做那么多的开源项目，甚至于把自己的某些项目开源。上周和一个来自阿里的朋友聊完之后，恍然大悟。比如阿里开源 druid, 那么在阿里云上就会有对应的服务。公司在选择这项服务时，很大程度上会选择信任这个服务。（开源，我可以查看源代码，我还可以提交修改意见）。 该类型常见是云服务公司：阿里（云）、腾讯（云）、华为（云）等 咨询费 这类商业模式常见于开源项目的早期，尤其是个人类做的较好的开源项目。公司使用某个开源项目后，需要邀请作者（专家）到公司内进行讲解、部署、或其他服务。 例子就太多了，就不一一列举。 基金会 这个商业模式，或许是现在的主流。许多的开源项目都是来自于 Apache基金会、Linux基金会、自由软件基金会、CNCF、Cloud Foundry基金会，Open Stack基金会等等。 而每个基金会又扶持了自己生态下面的很多项目。 我们来观察，在区块链里面，做生态的公链也存在自己的基金会。如以太坊基金会等。 版权声明 本文采用 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中文文档
2019/4/6
articleCard.readMore提升敏捷力的3个步骤
提升敏捷力的3个步骤 组织如何能够超越普遍的愿望，以便更具适应性并实现企业范围内的敏捷力呢? 我们的调查结果和深入访谈强调了敏捷在塑造高度竞争、创新领导者方面的关键作用，和滞后采用敏捷方法的风险所带来的收入增长停滞和客户不满意。根据这些数据，我们建议组织采取以下三个步骤来提高敏捷力，以获得明显的竞争优势: 打造具有敏捷思维模式的高管团队 雇用并培养合适的人才组合 培养敏捷友好的文化和组织结构 这些战略使组织(其中许多组织被创新所颠覆)扩展整个组织的敏捷力，以实现可持续的业务增长和成功转型。 – 上述摘自《福布斯观察》关于Scrum联盟的报道 上述的3个步骤对于一个组织的敏捷转型，是非常关键的。 如果先做1再做2，就是从上往下（top down） 如果先做2再做1，就是从下往上（bottom up） 而3是基础，是1和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中文文档
2019/4/6
articleCard.readMore产品经理和开发团队的关系
产品和技术之间的关系 今天微信有个朋友来咨询一个问题： 姜老师，请教个问题。现在很多公司喜欢把技术和产品分开作为平级。产品团队负责出需求，技术团队只负责实现需求。这种方式我感觉对市场导向的产品会出现需求和实现严重脱节…怎么解决这个问题呢？ 回答：首先从问题的提出者来看，他已经意识到问题了 – 需求提出和需求实现严重脱节。 在解决这个问题之前，先澄清一下在敏捷开发（尤其是说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中文文档
2019/4/5
articleCard.readMore你看到的世界不是真实的世界
你看到的世界并不是真实的世界 你以为你看到的世界就是真实的世界吗？ 假设这样一个场景： 在一个拥挤的停车场里，你正在慢慢开找车位。你发现前方不远处有一个空车位，正在你准备开过去停车时，突然飞速开过来一辆车一头扎进去占上了。 请问此时你怎么想？ 这个车位是我先来的，他在抢我的车位！该死的！ 正当你要去理论的时候，对方车上下来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中文文档
2019/4/4
articleCard.readMore从困境走向成功
从困境走向成功 北京今天天气晴朗，是个好天气，适合多读书。 今天推荐一本引导工具书 – 《从困境走向成功》 本书以小说为题材，由浅入深的介绍了： 实效的团队方法 深度沟通的团队方法 复杂冲突的团队方法 最后还介绍了CSA（Clarity, Solution, Action）工作坊的模型与设计。 实效团队方法 在实效团队方法中，介绍了几个很实用的引导方法，我也在培训中经常用到的： me we us – 个人先梳理观点、想法，然后小组整合，最后课堂梳理出结果 艺术画廊 – 适合提出问题，由大家的双脚法则来决定他们想工作于哪些问题上 深度沟通团队方法 这里介绍的两个方法是比较复杂（需要一定引导基础）的，如： 欣赏式探询 – 基本概念来自于同名书籍。 欣赏式探询 世界咖啡 – world cafe 复杂冲突团队方法 开放空间是另外一个很复杂的引导方法（或心态），参考资料。书很薄，容易阅读，但是要掌握还是很不容易的。首先从心态上要能接受各种变化，其次结果也往往会和预期不一样。 最后附上一篇 开放空间与世界咖啡馆 的对比。 思考 引导是Scrum Master必备的一项能力，也是培训师的一项利器。尤其在设计互动工作坊的时候，非常考验引导的能力。这是一本以介绍工具为主的引导书，可以很容易的先了解一些基础工具（每个工具介绍的并不足够详细）。如果想要深入了解，建议去阅读其他引导书籍，如《引导 : 团队群策群力的实践指南》《引导的秘诀 : 通过团队合作获得结果的SMART指南》等等。 引导，从我个人的经验来看，知道概念很容易（入门简单），想要精通就必须经过大量的实践、总结。 每日问题 你本周读了哪些书，可以留言推荐一下。 广告时间 订阅邮件列表 - 我有一个梦想 和BoB面对面学习Scrum 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！
2019/4/3
articleCard.readMore你在变成连自己都讨厌的人吗
你在变成自己讨厌的人吗 昨天在朋友圈看到一个朋友的分享： 我开车的时候最讨厌两种人： 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中文文档
2019/4/3
articleCard.readMore市场的基本原理
市场基本原理 市场的基本组成是买方和卖方，即供需关系。 现存的经济中，最主要的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中文文档
2019/4/2
articleCard.readMore使用谷歌Google的小窍门
你会用谷歌吗？ 作为互联网一代，每天我们都在用各种搜索。查一个商品价格，查一个学习资料，查找一个工作中遇到的问题，等等。 最好用的搜索引擎，莫过于谷歌（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中文文档
2019/4/1
articleCard.readMore为什么敏捷不提倡子团队
为什么敏捷中不提倡子团队 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.
2019/3/31
articleCard.readMore不要推敏捷
不要推敏捷 推还是拉，在专业的敏捷教练眼里答案很明显。 从上图我们可以看出来，如果是一个系统由多个子系统组成（常常是这样的），推很容易导致 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中文文档
2019/3/30
articleCard.readMore什么是价值
什么是价值 价值就是我们想要什么。 光这么说太抽象，我们用几个例子来说明一下： 如在软件开发行业中， 对于创业公司，我们想要获得投资 对于新产品，可能我们最想获取新用户 对于一款老产品，总会卡顿，那么性能是我们想要的 对于电商系统，我们想要多快好省 对于打车产品，我们想要服务及时贴心 因此对于不同的产品，所提供的价值是不同的，但最终相同的是，它(产品)都提供了我们想要的。 敏捷软件开发，是以价值驱动的软件开发方式。 最终的价值，需要从用户或客户视角来观察，这是有价值的。 但对于业务人员来讲，也是有价值的。 对于管理层来讲，也是有价值的。 对于开发人员来讲，也是有价值的。 并且，这里的价值是可以层层传递，即对于用户或客户有价值的，通常来讲对于业务人员、管理层及开发人员，也是有价值的。 但是对于开发人员有价值，而对于用户或客户未必有价值。 因此，通常我们说的价值，大部分是从用户或客户视角来说。 如何度量价值 上文我们已经明确了价值的定义，接下来我们看看如何度量价值。 首先，度量价值是很有必要的。但这是一个世界难题。 度量价值，和任务的估算有相似之处，即没有准确的答案，只有大致的估算。 其次，度量价值既然和任务估算相似，也可以用相对估算的方式。即一个特性(feature)的价值和另一个特性的价值直接进行对比。 使用L,XL,XXL或者斐波那契数列进行估算。 最后，一个产品的特性按照价值排序后，不是说所有的特性都需要完成，而是要对比团队的投入（即成本）。 比如团队一周的成本是10万，而一周完成的特性只能带来2万元的价值。 显而易见，团队不应该完成这些特性。 但这些数字都是后来才会统计到的，所以这里需要团队及产品负责人有很强的价值判断能力。 About Bob Jiang BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区（hiblock.net）发起人 中国北方的第一位CST（Certified Scrum Trainer） 国内的敏捷（Agile）大咖 敏捷变革中心（Center for Agile Transformation）合伙人 敏捷一千零一夜社区合伙人 敏捷之旅核心组织者 《Scrum精髓》译者 Bob的博客 Github: bobjiang Twitter: @bobjiang123 Solidity中文文档
2019/2/18
articleCard.readMoregithub ssh push不用输入密码
Github Push的时候不用输入密码 Github已经配置好SSH链接，但是每次 git clone 或者 git push 的时候总是需要输入密码。 前提1：需要在自己的电脑本地，不要在公共电脑上进行如下配置。 前提2：已经有自己的私钥。 $ ssh-add -K ~/.ssh/id_rsa -K 的含义是加入到 KeyChain 中，这样电脑重启后，依然可以有效（即不用输入密码） About Bob Jiang BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区（hiblock.net）发起人 中国北方的第一位CST（Certified Scrum Trainer） 国内的敏捷（Agile）大咖 敏捷变革中心（Center for Agile Transformation）合伙人 敏捷一千零一夜社区合伙人 敏捷之旅核心组织者 《Scrum精髓》译者
2019/1/3
articleCard.readMoreAgile is not quick
Agile is not agile Definition of agile 1 : marked by ready ability to move with quick easy grace e.g an agile dancer 2 : having a quick resourceful and adaptable character e.g an agile mind – from m-w.com From above information, there is a word “quick” in both definition. So many people believes Agile is “agile”, which means “quick”. Manifesto for Agile Software Development came out in 2001 by 17 software prioneers.
2018/12/27
articleCard.readMore什么是GitCoin
Gitcoin Gitcoin 从名字上来看，是一个 coin 的项目，但实际上它是一个没有 coin 的项目。 我是2018年3月份就了解到这个项目，当时被项目的使命所鼓舞 (#givefirst)，之后便一直关注着该项目。 Gitcoin是一个非常棒的，结合了区块链与开源软件的项目（即blockchain + open source）。 通过货币化的方式，支持github上的repo维护者，以及奖励github上的开发者（即贡献者） 如果你是一个开发者 开发者可以在Gitcoin 上面，通过 issue explorer 查找匹配你的技能的开发任务。 通过完成任务，获得奖励。这里的任务可能包括： 特性（功能）开发，一般不会很大一块功能 缺陷修复 测试 等 如果你是一个github repo维护者 如果你在维护一个github仓库，碰到了某个难题。（比如某个区块链的项目，碰到了密码学算法的问题） 你可以通过悬赏的方式，寻求全球的帮助。你的问题，或许已经有人完美的解决过。 所以来Gitcoin 上发布赏金计划吧。 Gitcoin使命（mission） 如有翻译不到位的地方，欢迎邮件 bob@hiblock.net 以下价值观来自于 gitcoin mission Gitcoin是价值和使命导向的分布式运动，目标是驱动变革及增长开源社区。 我们希望： 打造一个世界，每个人可以不需要他们的工作，就能达到财务平衡 软件开发者找到工作非常容易，就像我们用Uber一样 打造激励一致的网络社区，特别是现金与劳动之间相匹配 我们相信： 开放的标准和丰富的协议，以及用标准赏金(StandardBounties)构建的Gitcoin – 一个基于以太坊的开放、免费、公平的赏金协议 ICO和代币化不是我们最好的商业模式。我们没有代币。 区块链是开源项目资助的变革动力。开源的资助和开源的工作将构建与开源的金钱上。 我们的价值观 协作 诚实 谦逊 同理心 减少压力 包容 首先给予 我们的行为 我们改变世界。而不是世界改变我们。 秀出来，而不是说出来。 我们是清晰且直接的。 我们寻求平衡。 我们挑战现状且愿意被挑战。 我们修复重复的问题。 我们识别并验证假设 关注人（而不是仅仅关注任务） 倾听 实用主义大于经验主义 About Bob Jiang BoB Jiang
2018/12/24
articleCard.readMore2018年度总结
2018年度总结 2018就要过去了，又是一年总结潮 今年的总结主要分为两大部分： 敏捷 区块链 2018年完全应用帕累托原理，即20%的时间投入在敏捷上，产出80%的收入；80%的时间投入在区块链上，产出20%的收入。 2019年时间的投入大致维持不变。 敏捷 2018年敏捷的大部分时间，用在讲课上。 为学日益，为道日损。 今年损的厉害，2019年注意平衡，投入更多的时间游学。 另外2019年敏捷方向有个新计划，已经启动，有兴趣的同学可以持续关注。 持续投入敏捷社区 开辟海外市场 区块链 2018年1月开始，筹建HiBlock区块链社区。 今年最大的收获是，任何事情都要有“商人”思维，即这个事情的赢利点在哪里（不管是眼前收益还是长远收益） 同时要兼顾短期收益和长期收益。 只有长期收益，会饿死； 只有短期收益，会迷茫。 在今年，HiBlock区块链社区重点专注于两件事情： 技术沙龙，截止到目前已经举办了70+场，详情参考 黑客马拉松，在国内举办过3场黑客马拉松，详情参考 2019年，继续专注于这2件事情，想要学习区块链技术的开发者，可以关注我们社区 Github 2017年度收获 这里我不仅回顾2018年，同时也把2017年的收获再次记录回顾。 加强记忆。 2017年我有2个收获： 选择大于努力 选择离钱近一些 选择大于努力 有的人，非常努力，可是并没有什么结果（产出）。 好比是一年的工作经验，重复了10年。 再怎么努力，也枉费。 生活、工作的现状，都是选择的结果。 那么就需要花大量的时间来思考，我面临的选择是什么，如何做出最优选择。 选择离钱近一些 我是一名培训师，CST，这个行业会离钱的流动相对较远。 举个例子， 业务人员，离钱很近 IT人员，离钱相对远了一点 售后服务人员，离钱更加远了一点 培训咨询，又远了一层 如果想要赚更多的钱，可以选择离钱的流动更近一些。 当然，人的一生不仅仅是钱，还有很多其他重要的事情。 因此这个只是一个收获和体会， 我会持续的在区块链行业进行探索， 寻找自己生命的意义。 总结 2017年2大收获： 选择大于努力 选择离钱近一些 2018年最大收获： 商人思维 About Bob Jiang BoB Jiang
2018/12/20
articleCard.readMore免费还是付费
这个物质极大丰富的社会 充斥着免费的东西，如 免费文章、免费课程、免费大白菜（真的是大白菜哟） 那么在这些免费的背后，对于消费者的你，付出的代价是什么 互联网时代（或信息时代），最昂贵的是注意力 虽然你没有付出金钱（免费），你的注意力被吸引到这个免费的产品上了 如果该免费产品解决了问题，这还是不错的结果 如果只是个噱头，那么你的注意力就浪费了 因此在这个物质丰富的社会 我们可以通过付费来进行筛选 过滤那些我们不需要的服务或产品 但这不代表付费一定是好的 无论免费或付费 真正解决问题的产品 或者说真正了解了问题本质并解决的产品 有人愿意买单 About Bob Jiang BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区（hiblock.net）发起人 中国北方的第一位CST（Certified Scrum Trainer） 国内的敏捷（Agile）大咖 敏捷变革中心（Center for Agile Transformation）合伙人 敏捷一千零一夜社区合伙人 敏捷之旅核心组织者 《Scrum精髓》译者
2018/12/19
articleCard.readMoreFree as in freedom
Free as in freedom is a book named authored by Richard Stallman who is the founder and envengilist of the free software inspired deeply by his spirit of radically thinking out of the box free as in freedom is introduced 4 levels of freedom as following: 四项基本自由 如果一个软件是自由软件，那么它必须为用户提供以下四项基本自由：[1] 自由度0：无论用户出于何种目的，必须可以按照用户意愿，自由地运行该软件。 自由度1：用户可以自由地学习并修改该软件，以此来帮助用户完成用户自己的计算。作为前提，用户必须可以访问到该软件的源代码。 自由度2：用户可以自由地分发该软件的拷贝，这样就可以助人。 自由度3：用户可以自由地分发该软件修改后的拷贝。借此，用户可以把改进后的软件分享给整个社区令他人也从中受益。作为前提，用户必须可以访问到该软件的源代码。 Reference About Bob Jiang BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区（hiblock.net）发起人 中国北方的第一位CST（Certified Scrum Trainer） 国内的敏捷（Agile）大咖
2018/12/18
articleCard.readMoreSingapore
On the way back Beijing, and then fly to Singapore in 1.5 hours pray for no delay Singapore, it is a nice city, I have been there for several times, a bit hot, but diversity, and multiple cultures, going to join EthSingapore.co hackathon since is a short journey this time, I am full of schedule now, if you would like to make an appointment, let us make it happen.
2018/12/7
articleCard.readMoreDo right things
do right things, do things right, very similar, but total different consequence, if focusing do things right, then easy to dive into the details if focusing do right things, then needs the deep thinking, like: meditation reading writing etc. so I would like to do right things first, and then do things fast (not right) I don’t know which way is right, and then I have to do things fast, and in small,
2018/12/6
articleCard.readMoreGithub page service
It is easy to build a web page by choosing github page service, which could provide basic static web page. you can visit github.io to get more information. Here is also an example for ERC875 There are several simple steps for you: have a github account sign in create an organization named “domain” related with your business (e.g erc875) create a repo named “domain.github.io” in your organization upload (github push) your html or markdown to your repo More details please visit github.
2018/12/4
articleCard.readMoreThis is marketing
This is marketing, a new book from Seth Goddin, a genius of marketing, I am one of his fans, learning how to do marketing in the new world, digital age, his latest book is a great encapsulation of many of his major themes: The job of marketers is to change people through stories Go for the smallest viable market (as opposed to the minimum viable product) “When you know what you stand for, you don’t need to compete.
2018/12/1
articleCard.readMoreTo be a businessman
why to be a businessman This is insight from my experience of 1 year entrepreneur. Why to be a businessman. The reasons are: Each one is for “money” (at least some kind of “money” - here what I mean is short term, money; but long term might be reputation or shape.) there are 2 types of “money”, one is short term, which means get cash shortly; the other type is long term, which means we could get recognition/reputation, not cash.
2018/11/29
articleCard.readMoreSydney Blockathon
背景介绍 自去年起，天钥团队及区块链社区 bitfwd 开始了一个实验，即主办澳大利亚的区块链黑客马拉松（Blockathon），聚集社区之力开发去中心化的解决方案。而这一活动也带来了伟大的成果，从那之后我们在悉尼，北京，上海和立陶宛都开展了国际性的区块链马拉松，效果令人惊叹。临近年底之际，我们又把它带回了梦开始的地方 - 澳大利亚悉尼。 从11月初开始，我们就开始举办预热研讨会。bitfwd 社区邀请到了 Connor Wiseman，Mark Pereira 和 Jasper Verhoeven 等人，来帮助教育参赛者必要的区块链，智能合约及用户体验设计等方面的基础知识。 正式的区块链马拉松于 11.23 日- 11.25日期间在新南威尔士大学 Michael Crouch 创新中心举行，共 11 支来自澳大利亚，欧洲，美国，中国等地的开发团队参与了本次比赛。经过3天的激烈角逐，在由 Sergei Sergienko（Chronobank首席执行官），Emma Poposka（Brontech首席执行官），Kee Jeffreys（Loki首席技术官），Adriana Belotti（区块链专业人士首席执行官），Daniel Bar（Tenzorum首席执行官）和神秘嘉宾 Aeron Buchman（ Web3基金会执行副总裁）组成的超强评委阵容评审下，产生了本次比赛的前三名。 获奖队伍 第一名：ZKR 一等奖授予了 ZKR（Zero-Knowledge Relayers），它是一个有助于简化匿名系统 Zk-Snarks 使用成本的工具包。它将有助于匿名投票，匿名奖品收集等匿名系统的应用开发。来自澳大利亚昆士兰州的 Kendrick Tan 作为该项目的领导和主要开发人员登台领奖，表示了获奖的惊喜之余，也为能开发区块链生态系统中非常需要的项目感到骄傲。 第二名：M3 二等奖由另一位昆士兰人 Harry Jubb 以及他的项目 M3 获得，这是一个从 Gnosis Safe 钱包分叉而来的移动多签名客户端。他还着手改进了客户端的移动UI，使普罗大众更容易用其验证他们的多签名认证。自此，来自昆士兰的团队囊括了本次赛事的前两名！ 第三名：TwoUp 该团队使用区块链技术重制了澳洲节日 Anzac Day 上的传统游戏 Two Up（同时抛掷两枚硬币，通过正反面的不同来判断输赢 ）。该项目通过使用副优化（vice optimisation）极大的减少了赌博游戏的有害影响，因此获得三等奖的殊荣。 花絮 最后值得一提的是本次活动的人民选择奖，它们被颁发给了两个 11 岁的男孩 Baxter 和 Liam ，他们使用儿童编程软件 Scratch 建立了一个名为“统治世界”的区块链游戏。其中能够建立一个城市，公民还可以使用加密货币来纳税和发展他们的城市。在这里不得不感谢 Nick Addison 建立了以太坊区块链系统和 Scratch 之间的连接，让下一代也能接触并了解到最前沿的新兴科技，以及它们所蕴含的深意。
2018/11/28
articleCard.readMoreGitcoin Ambassador
What is Gitcoin Gitcoin is a community for developers to collaborate and monetize their skills while working on Open Source projects through bounties. So if you’re a developer, please come to visit Gitcoin, and goto issue explorer and look for your professional skills to make the world better. What is Gitcoin Ambassador Gitcoin Ambassador program is an initiative to grow community and invest in our (Gitcoin) contributors. Gitcoin is aiming to become the most community friendly open source project on the web.
2018/11/27
articleCard.readMorePowerful questions for scrummaster
questions A good question is a window to the heaven. During working hard on a solution or problem, if we can ask a good question, we could get insights always. For a ScrumMaster, who is a new role from Scrum, he should have good question skills, and always challege team by question them. E.g ScrumMaster could leave the situation to the team. In the morning the team had daily scrum, but someone was late.
2018/11/26
articleCard.readMoreApplications in Ethereum
Background I twittered a message to list current awesome application in ethereum. Maybe some are not awesome. Let’s review the list, and firstly categorize them: Infrastructure Wallet DEX DAO Game ERCs Here are the lists for applications I collected by twitter: infrastructure Ethereum (ICO) Etherscan Infura Metamask Brave MyCrypto Parity geth wallet imToken AlphaWallet MyEtherWallet Pillar Status hard wallet DEX Kyber … Shapeshift … airswap 0x DAO Maker DAO Aragon Game CryptoKitties Loom others gitcoin Gnosis (predict) Golem substratumnet windingtree sun_contract (energy trading) DOS (oracle) ERCs ERC20 ERC721 ERC875 ERC1337 (8x protocal) other blockchains EOS NEM Stellar Tezos to be continued.
2018/11/23
articleCard.readMoreThink BIG, but act small
Think BIG, act small First heard this sentence ‘think big, but act small’, I am totally inspired. Why? I am a trainer, and have many friends like me as trainers or consultants. Often I have some ‘great’ ideas, but I didn’t move forward, so I would miss some opportunities as well. Then if I have any idea, and would like to make it real, and I have to do something, aka.
2018/11/22
articleCard.readMore交付还是交代
交付还是交代 了解过Scrum的同学，或拿到 Certified Scrum Master (CSM) 认证的同学，应该都知道Scrum是一个框架，3-3-5-5，分别是： 3个角色 3个工件 5个事件 5个价值观 然而这里面有很多重点，或可能被人忽略的地方。 今天要反思的一个点是我最近1年的感悟，即交付。 什么是交付 交付不仅仅是交出答案，而更应该是有“响”，即付出有对应的回报（最直观的回报，可以用金钱衡量，或可以和金钱挂钩的度量）。 举个简单的例子：比如我们要开发软件中的一个特性（feature）。 如果只是完成了开发和对应的测试工作，（或甚至有的只完成了需求分析或设计文档工作）那么这个时候的特性，无法使用，也不能为团队带来直观的回报。 可能团队会很辛苦，996，天天加班。但作为没有办法度量结果的团队，只能说他们有了交代，而不是交付。 什么是真正的交付呢？ 交付指的是，特性真正完成，可以交付给客户使用。由此，客户（以及用户）的问题得到真正的解决，并且变得很高兴。然后团队也变得很兴奋。（当然，客户变得高兴之后，从长远看，收入也会变得顺畅）。 我们要选择交付还是交代 答案毋庸置疑，但往往我们会局限于自己的视角，以为我们选择的是交付，而实际是交代。 我们可以尝试通过如下的问题，来检验是否是交付： 这个工作对于客户的价值是什么？ 这个工作是否解决了客户的某个问题？ 这个工作是否节省了客户的时间或金钱？ 这个工作是否帮客户带来了更多的用户？ 还有更多的问题吗？欢迎一起来探讨 赶快扔下那些交代，一起来专注于交付吧！ 想要学习 CSM敏捷认证，一起来报名吧！ 关于Bob Jiang BoB Jiang HiBlock区块链社区（hiblock.net）发起人 中国北方的第一位CST（Certified Scrum Trainer） 国内的敏捷（Agile）大咖 敏捷变革中心（Center for Agile Transformation）合伙人 敏捷一千零一夜社区合伙人 敏捷之旅核心组织者 《Scrum精髓》译者
2018/11/21
articleCard.readMoreWhy it is important with retrospectives
Retrospectives 回顾 本文描述的回顾（retrospectives），是 Scrum Guides 中描述的事件之一，即周期性的反思工作流程与方法。 Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。 … … Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的。Scrum Master 教导大家遵守时间盒的规则。Scrum Master 作为 Scrum 过 程的责任者以及团队的一员参加该会议。 Sprint 回顾会议的目的在于: 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何; 找出并加以排序做得好的和潜在需要改进的主要方面;同时, 制定改进 Scrum 团队工作方式的计划。 Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们能在下个 Sprint 中更高效更愉快。 在每个 Sprint 回顾会议中，Scrum 团队通过适当地调整“完成DoD”的定义的方式来计划高产品质量。 在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。 在下一个 Sprint 中实施这些改进是基于 Scrum 团队对自身的检视而做出的适当调整。虽然改进可以在任何时间执行，Sprint 回顾会议供了一个专注于检视和适应的 正式机会。 – 摘自于《Scrum指南》 Think BIG, Act small 从今天（2018年11月20日）起，每天写一段文字。 无论是敏捷、Scrum、社区、区块链、或任何有感而发的内容，要做一个每日的记录。
2018/11/20
articleCard.readMoreScrum指南 Scrum权威指南 游戏规则
Scrum 官方权威指南 收听有声版 | 官网下载PDF 由Scrum创始人 Ken Schwaber 和 Jeff Sutherland 开发并维护 版本：2017中文版 Scrum 指南的目的 Scrum 是用于开发、交付和持续支持复杂产品的一个框架。本 Scrum 指南 包含了 Scrum 的定义，其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则。Ken Schwaber 和 Jeff Sutherland 创造了 Scrum，Scrum 指南也由他们撰写并提供。总之，他们是 Scrum 指南的后盾。 Scrum 的定义 Scrum（名词）： Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付最高价值的产品。 Scrum 是： 轻量级的 易于理解的 难以精通的 Scrum 是一个框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的工作上。Scrum 并不是一种过程、技术或决定性方法。倒不如说，它是一个框架，在此框架中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和工作技术的相对成效更加清晰地显现出来，以便您可以持续改进产品、团队和工作环境。 Scrum 框架由Scrum 团队以及与之相关的角色、事件、工件和规则组成。框架中的每个部分都有其特定的目的，其对于 Scrum 的成功与使用是至关重要的。 Scrum 的规则把角色、事件和工件组织在一起，管理它们之间的关系和交互。对于 Scrum 的规则描述将会贯穿全文。 使用 Scrum 框架的其它不同特定技巧将不在本文中描述。 Scrum 的应用 Scrum 最初是为了管理和开发产品而开发的。从上世纪 90 年代初开始，Scrum 在全球范围内已得到了广泛应用：
2017/11/12
articleCard.readMore不清晰的完成-敏捷坑人系列
摘要： 本文主要描述Scrum中完成的定义（Definition of Done，DoD）以及验收标准（Acceptance Criteria，AC）的用法。 “坑”的描述 完成的定义，即DoD不清晰，不仅仅是概念本身可能存在误解，常常由深层次的原因引起的。 完成的定义 与 验收标准 实际可能的例子 每日站会上，团队成员A：“昨天我完成了条目1！今天我将开始工作于条目2上。” 两天后，产品负责人找到团队，“条目1怎么回事，这个流程和我想要的并不一样……” 上面这个场景，每天都在不同的团队上演着。为什么会发生这样一幕？有可能他们缺少完成的定义与验收标准 完成的定义（摘录自Scrum指南） “完成”的定义 当产品待办列表项或增量被描述为“完成”时，每个人都必须理解“完成”意味着什么。虽然在不同Scrum团队之间或许会存在显著差异，但是每个团队成员必须对完成工作意味着什么有相同的理解；以便确保透明化。这就是 Scrum 团队的“完成”定义，用来评估产品增量是否完成。 这一定义也同时被用来指导开发团队了解在Sprint计划会议时能够选择多少产品待办列表项。每个 Sprint 的目标在于交付符合 Scrum 团队当前“完成”的定义的潜在可交付功能增量。 开发团队在每个 Sprint 都交付产品功能增量。这一增量是可用的，所以产品负责人可以选择立即发布它。 如果“完成”的定义对增量来说是开发组织的惯例、标准或指南，那么所有Scrum团队都必须遵守它，以此为最低标准。 如果增量“完成”的定义不是开发组织的惯例，那么 Scrum 团队中的开发团队就必须制定适合于产品的“完成”的定义。如果系统或产品发布由多个 Scrum 团队一起开发，那么所有 Scrum 团队中的开发团队必须一起参与制定“完成”的定义。 每个增量都添加至之前的所有增量上，并且经过彻底地测试，以此确保整合在一起的所有增量都能工作。 随着团队的成熟，“完成”的定义会扩展，包含更为严格的标准来保证更高的质量。当使用新定义时，在先前“完成”增量中可能会发现尚需完成的工作。任何产品或系统都应该对其上面开发的工作有“完成”的定义。 在Scrum指南中我们可以看出： 整个产品有统一的完成的定义 完成的定义是Scrum团队制定的，并共同理解的 每个团队可以定制自己的完成的定义 完成的定义可以扩展（当团队成熟之后） 完成的定义一个例子（有下划线的内容为当前产品的完成的定义，随着团队成熟，其他未有下划线的部分，可以逐步加入到完成的定义中）： 验收标准 验收标准（AC）是针对单个条目（如用户故事）而言的，如何验收（或确保）单个条目是满足客户要求的。验收标准具有如下的作用： - 定义用户故事或特性的边界 - 帮助厘清客户要求 - 团队与客户（以及产品负责人）达成共同理解 - 根据验收标准可以有效的产生测试用例 验收标准的一个例子： 用户故事： 作为一个互联网银行用户， 我想要看到每日交易明细， 以便我很清楚每笔交易之后自己的账务情况。 验收标准的例子如下： - 默认显示最近一周的每笔交易明细 - 显示当前账户余额 - 显示指定日期时间段的交易明细 ###完成的定义与验收标准
2017/11/9
articleCard.readMore当心陷阱会拖慢您的组织敏捷性
引言 敏捷火热，随之出现很多敏捷热词，比如敏捷组织、敏捷营销、敏捷管理、敏捷blah blah。在这么多敏捷词汇背后，映射出敏捷已经受到越来越多的行业与人群的关注。然而就在我们日常工作的组织中，有很多与敏捷相悖的陷阱（或常识）。这里和大家分享如下几个： 跨地域团队 狂热的敏捷 外包客户服务 大规模敏捷的困扰 SAFe or safe 跨地域团队 软件开发工作，没什么比得上大家坐在一起更高效了。 “通讯基本靠吼，交通基本靠走”，虽然这只是一句顺口溜，然而放在软件开发工作中是非常贴切的。 我想要寻求某个问题的答案时，只要站起来走到同事身边，吼一下就可以了。 现代移动互联网时代，越来越多的工具尝试代替人与人之间的沟通，比如Skype, Slack, Trello, Teambition, Leangoo,等等。发个消息过去之后，就如石沉大海没有了回应。这是一种什么心情呀。 因此，对于软件开发工作不要跨地域团队。（注：这里的地域可以大到国家，小到楼层） 狂热的敏捷 组织敏捷转型催生了对于敏捷培训师、引导者以及咨询师的大量需求。很自然地出现了求大于供。这种情况下就会出现一些浑水摸鱼的人，来满足企业和组织的需求。如果雇佣了一名知识与经验不足的敏捷咨询师，组织很快就会对于敏捷失望透顶，失去兴趣。那么以后再想重整旗鼓就很难了。 因此选择靠谱的敏捷培训师、咨询师是很重要的第一步。 外包客户服务 如果你和客户之间没有直接的链接，那么你将失去创新的机会。你也就不会得知客户真正想要什么。很不幸的是，很多组织在缩减成本，往往会把与客户直接对话的客服部门进行外包。 停止外包你的客户服务工作吧！ 大规模敏捷的困扰 我不相信有一个完美的框架，可以帮助组织很好的实现大规模敏捷。以前没有，以后也不会有。盲目地相信有这种解决方案的人，是懒惰的，是想逃避责任的。 在选择或实施大规模敏捷之前，需要问以下问题： 为什么要采用大规模敏捷 想要解决的组织问题是什么 SAFe还是safe SAFe是一种以价值流为核心的大规模敏捷方法。组织因此可能变得更高效或以客户为中心。但很多企业选择SAFe的时候并不理解敏捷宣言，不理解敏捷的价值观。寄希望于一套完整的框架方法可以帮助组织进行整体一次性的转型。SAFe方法提供了一套完美的完整的框架（包含原则、方法、实践），给高层领导者一种很安全（safe）的感觉。然后组织根据自己的情况进行裁剪与适应。 在转型的初期，这是奏效的。然而随着时间的推移，转型的深入，这种方法很可能无法完全适应组织的需求。因为SAFe并不提及组织结构的改变。 而企业或组织的核心是盈利，是需要完成产品开发。另外一种大规模敏捷方法LeSS，是以产品为核心，特性团队（组织结构的变化）为基础，以系统思考、精益思想等为原则的框架。 想要大规模敏捷，除了问下上述的两个问题，更多要全局思考。 有关LeSS更新信息请参考
2017/8/20
articleCard.readMoreCSM课程可以申请PDU
什么是CSM课程 CSM的课程及证书已经赋予你16个SEU的学分，可以用于后续申请CSP认证。鼓励大家通过申请成为CSP来继续提升你的Scrum经验及技能。 对于PMP，你可以参考下面的指引去申请获得PMI的16个PDU学分。我们本人都没有PMI网站访问的权限， 下面信息不一定最更新，但我相信可以作为参考开始你的学分申请。（听说PMI在12月全面更新了PDU申请的方法，若你能跑通新的流程，请分享细节给我参 考。应该有一个课程内容PDU比例的分配，我建议：Technical 12 / Leadership 2 / Strategy 2） 登入成功后，在首页导航栏选择myPMI 进入myPMI页面后，在页面右侧，会有一块蓝色区域“Report PDUs” 进入“Report PDUs”页面后，选择“Course or Training” 在“Course or Training”完成对应信息，例如provider、activity、description等相关信息（相关信息请看下面培训师信息，若有不全的，请告知我，我要持续完善） 在“PDU Claimed”的三大领域分布16PDU，可以按照12、2、2分布（我的建议） 勾选I agree this claim is accurate，点击Submit即可 完成以上操作，可在Dashboard和Claim History查看~ 关于培训Provider的具体信息，在你填写PDU申请时，你可以使用如下信息： Provider: Bob Jiang, CST （请留意，你并不需要在PMI供应商列表里匹配到我们的这个信息） Activity: Certified Scrum Master (CSM) Summary: A 2 fully days training covering fundamental Agile project management and Agile delivery mindsets, principles, process, ceremonies, roles, artifacts and related techniques based on Scrum framework.
2017/7/30
articleCard.readMore宝宝说敏捷（BoB Jiang敏捷新闻） - 2017年03月
宝宝说敏捷简书专栏开通，欢迎大家关注。 宝宝说已注册域名，现招募一名网站设计的小伙伴，一起搭建宝宝说网站。 对于宝宝说敏捷如果您有任何想法或建议，欢迎我和联系。 内容大纲 新闻 社区 荐书 课程 新闻 3月我陆续写了9篇文章，具体可以参考我的简书专栏。 主题包含敏捷与成长，如Agile的起源、Scrum和看板的区别、如何快速学习新知识、理想与现实等 社区 Agile1001四月份活动预告 - 4月16日 DevOps实战 荐书 《在Toyota学到的只要纸1张的整理技术》- 本书的核心内容是思路整理，工具是用的一张纸。简短易用的一本书。具体可以参考链接。 课程 - Certified Scrum Master (CSM) 敏捷认证课程 2017年4月16日17日 上海 https://yihuode.io/activities/444 2017年4月24日25日 深圳 https://yihuode.io/activities/436 2017年5月25日26日 北京 https://yihuode.io/activities/419 关于我 姜信宝 （Bob Jiang） 中国北方第一位CST（Certified Scrum Trainer） 资深敏捷教练、创新教练 旨在帮助企业改进工作方法以取得更好的商业价值 Certified LeSS Practitioner，《Scrum精髓》的译者 Agile1001 (敏捷一千零一夜)联合创始人 我的博客 https://www.bobjiang.com 邮件： bob@bobjiang.com 微信： bob_jiang_xinbao 电话： 13910939018
2017/4/10
articleCard.readMoreScrum的本质与看板方法的本质
自敏捷宣言以来，随着敏捷软件开发方法的普及，很多企业踏上了敏捷转型的道路。这里宝宝将跟大家一起说一下敏捷当前最流行的两个框架（Scrum和看板方法）——从它们的起源来分析各自的本质。 Scrum Scrum的起源 Scrum一词来源于英式橄榄球（rugby）中重新开始比赛的争球的术语（是体育术语，不是缩写简写）。详情参考Wikipedia。 Scrum之父Ken Schwaber和Jeff Sutherland为什么选择这个词呢？这是因为他们受到一篇1986年哈佛商业评论上的论文影响——《The New New Product Development Game》。论文中开篇提到了： > 许多公司意识到仅仅依靠高质量和低成本，已经无法从今天的市场中脱颖而出，它们还需要速度和灵活性。……而传统的顺序式或“接力赛”方法（比如按阶段的产品规划）可能和追求速度和灵活性的目标相冲突。相反，一种全局的或“英式橄榄球（rugby）”（团队通过前后配合传球的方式，作为一个整体单元推进）可能更好的适应了这种目标。 另外，在Scrum指南中也非常强调团队（开发团队），它们具备如下特点： 自组织的，没有人来命令（或告诉）团队如何把产品列表变成潜在可交付的产品增量。 跨职能的，团队作为一个整体，拥有开发产品增量所需的全部技能。 全职的，团队成员100%在团队内工作。 规模较小的，一般5-9人 虽然Scrum指南中还定义了Scrum框架的其他内容，但通过Scrum的起源（那篇论文）和指南中对于团队的描述，我们不难看出Scrum的本质是以团队为核心。 Scrum的本质 Scrum本质是以团队与产品（产品列表Product Backlog，这里就不展开介绍产品列表了）为核心。注意这里指的团队，和我们平时说的团队之间的差异。Scrum中的团队是自组织的、跨职能的特性团队。这样的团队的好处是： 特性（客户需求）在一个团队内完成，去除了移交、等待之类的浪费 团队的业务知识快速增长 团队稳定，从而有助于团队隐性知识的积累 > “搭班子、定战略、带队伍” ——柳传志 柳总的管理心法是在做事之前要先有一批志同道合的人，有班子，然后再考虑定战略。这个管理思路和Scrum是一脉的。Scrum的本质也是先打造自组织跨职能的特性团队，然后再遵守Scrum指南的其他规则。 看板方法 看板方法的起源 看板方法的重要来源是Donald G. Reinersten的《The principles of product development flow》。这本书强烈推荐大家读一下。该书中共介绍了175个产品开发的原则，其中不乏一些反常识性的原则，另外还介绍了一些具有实践性的方法： 改善决策的经济性 管理队列（对比一下肯德基和麦当劳的取餐模式，很有趣） 减小批量大小 应用WIP限制 去中心化 看板方法的本质 由上述Don的书中核心理论可以看出，（产品开发流动的原则）他强调的是流动以及价值流动，这个是看板方法的本质。看板方法通过一系列原则促进实现价值的快速流动，比如： 可视化 限制WIP 减小批量 管理度量队列 等等 Scrum和看板方法的对比 上面分析完Scrum的起源、本质和看板方法的起源、本质后，我们不难看出这是两个完全不同的解决问题的方法。 Scrum侧重于团队和产品，先有自组织跨职能的特性团队，然后围绕着产品列表进行交付。 看板方法侧重于工作事项，先让价值流动起来。 那么这两种方法孰优孰劣，这个很难衡量。以下仅代表个人观点： Scrum的特点： 打造真正的团队
2017/4/9
articleCard.readMore如何学会欣赏
2017年4月1日，是第九届一块的年会，我非常幸运地参加了这次“傻气与勇气”并存的年会。本次年会的主题是“用AI与未知共舞”。其中的AI是爱的谐音，也是Appreciation Inquiry的缩写。即用欣赏式探询与未知共舞。 两天的（4月1日4月2日）时间里，80多名来自全国各地的小伙伴齐聚西安，共同探索未知。在活动的第二天，收集了大家很多有关AI的疑问。其中一个问题的研讨给我非常大的触动。这个问题就是“如何锻炼欣赏的肌肉力？” 带领大家探索未知的是几位一块的伙伴（一折、Julia Zhu、任伟、嘉佑）。一开始一折跟大家分享了几个金句： The truth is local. 真相都是在地的。 意思是真相是每个人自己的视角观察到的。所有人的真相是并存的（也可能是冲突的）。 Your word creates your world. 语言创造了世界。 先不解释了，有兴趣的小伙伴可以当面交流理解这句话。（书面可能表达不是那么清楚）。 在这个过程中，大家对于真相，视角，以及身体里的恐龙（恐惧）展开了激烈的讨论。在争论快要失去平衡的时候，Julia开始带领大家探索未知。 一开始，Julia先问了大家3个问题： 现在每个人你自己是不是ok的？ 你认为场上几个引导师（一块的伙伴）是不是ok的？ 当下的气氛和环境是不是ok的？ 接着Julia介绍了一个okness模型，如下图 Okness模型 模型的三个角分别对应刚才Julia提问的三个问题，即我、他、环境。 首先是我自己当前是不是ok的？即我是否接纳当下的自己？当下如果我不舒服是因为什么，是否有察觉，是否接受？不能接纳自己的情况下，是无法做到欣赏的。 其次是他人当前是不是ok的？我是否可以接纳他人的状态？是否察觉到自己的情绪随着他人在变化，是否可以接纳这种情绪的变化。不能接纳的话，也很难做到欣赏。 最后是当下的环境是不是ok的？对于当下的环境我的觉察是什么，是否可以接纳这个场景，我的情绪是什么。如果无法接纳的话，欣赏也不是那么容易做到。 通过这三个层面我们发现，其实对于如何做到欣赏，有三个重要的步骤： 觉察 接纳 欣赏 上述3个步骤是层层递进。 最重要的是从觉察开始。我有没有觉察到……不论是自己的状态、情绪，他人的语言、情绪，当下的环境和场景等等，我是不是有这个觉察的能力。 那么如何锻炼自己的觉察能力？在座的小伙伴有不错的方法： 练习每日感恩日记 每日冥想 接纳。一旦我们觉察的能力提升，往往容易陷入苦恼的情绪中。因为好像突然之间发现了好多不如意的地方。那么这时候就需要开始接纳。接纳我是一个人，一个普通的人，不论什么情绪都是可以接纳的。甚至痛苦都是一个非常棒的礼物。（来自Hide Enomoto） 欣赏。觉察和接纳后，才有可能做到欣赏。当时大家在讨论的时候，有个伙伴分享她每天也会写感恩日记，可是觉得总找不到可以感恩的内容，练习1个月之后就无奈的停止了。我的个人感觉是她还是没有接纳自己，也可能是觉察还不够。而这个时候感恩日记会倾向于流于表面。 最后总结一下：想要做到欣赏，是一个循序渐进的过程。首先是觉察，其次是接纳，最后才是欣赏。而这里面关键的练习方法（或者工具）是每日练习感恩日记，或每日冥想（或者其他可以独立思考的方法）。 让我们一起来锻炼欣赏的能力吧！
2017/4/9
articleCard.readMore如何快速学习一个新知识
一听到学习，很多人就想起来在学校里听老师讲课的场景。这样的学习真的是一个好方法么？还有没有其他更好的学习方法呢？ 今天我就要跟大家介绍一个快速学习知识的方法：费曼学习法 费曼学习法的原理 “I learned very early the difference between knowing the name of something and knowing something.” - Richard Feynman “我很早就学会了知道名字和知道某事之间的区别”——理查德 费曼 学习不是要记住某事，而是需要理解并能将其融入到自己的知识体系中。 怎么样 费曼学习法有五步： 选择一个新知识 将这个知识讲给其他人听 查明这之间的知识差距（比如哪些地方讲不好，讲不清楚） 使用类比（最好是生活中的例子，尤其是专业知识，可以假设对方没有该领域的背景） 简化你的讲解（用更精炼的句子） 举例 本文就是一个最好的例子。为了记住费曼学习法则，我自己查找相关资料，并认真记录下来。（记录也是一个讲给其他人听的例子，不过这个是写给其他人看） 回应上面的五步： 选择一个知识（费曼学习法） 用博客记录下这个知识（强化学习） 一边写，一边找出自己哪里还没有搞清楚 费曼学习法，就像中国的古语“授人以鱼不如授人以渔”。要学会方法。 费曼学习法，是一个学习的方法。可以用来学习任何新知识。 总结 本文除了介绍费曼学习法，还有另外一个很重要的介绍新知识的三板斧，即Why, What, How。 Why - 为什么介绍这个知识，它的原理是什么，有什么作用。 What - 这个知识是什么 How - 如何应用 多数介绍的时候，是按照What How Why的顺序，也有可能打乱这个顺序，比如先介绍Why， 然后What How。 今天的关键字：费曼学习法；学习知识三板斧；
2017/3/30
articleCard.readMore我们反驳的是什么
开始今天的话题之前，先讲一点题外话。用面向对象的方法和大家介绍一下类的设计。 面向对象类图设计 类图设计 声明：由于手头没有合适的工具，所画的类图并不标准，但表达的意思都在图里了。 简单介绍一下这个类图：如上图所示，一共有两个接口，分别为Animal（动物）和Plant（植物）；动物这个接口有3个实现类，分别为Dog，Cat和Tiger，而植物这个接口有2个实现类，分别为Tree和Grass。这里省略了接口和类的内部定义。 假设现在有一个问题是，我们觉得有点热，想要凉快一点。针对这个问题，Dog类可能不会有什么好办法（假设狗真的无法解决这个问题）。不过有人发现Tree可以很好的解决这个问题。 那么我们能否把Tree（树）叫做动物呢？ 显然不可以！动物就是动物，植物就是植物。 狗也可能有办法让我们凉快一点，不过确实不如树提供树荫这个方案更好。但这无法改变狗是动物而树是植物，这两个概念！ 隐喻 第一节提到的类图，其实是一个比喻。现在我们换一下类图中的几个概念。比如 敏捷替换动物 Scrum替换狗 心理学替换植物 催眠替换树 现在假设某个组织内采用Scrum效果甚微（暂且不讨论是如何采用的），而恰巧催眠这种方法较好的激活了个人意愿，从而改变了组织。那么这种情况下，催眠能不能叫做Scrum？或者催眠能不能叫做敏捷？ 显然不可以！Scrum就是Scrum，催眠就是催眠！敏捷就是敏捷，心理学就是心理学！这是两个不同的概念。 我们反驳的是什么 上面两节里面讨论的概念，来源于最近敏捷社区里面的热议，从而也给我写这篇文章的灵感。 社区里面热议的焦点，主要集中于敏捷教练不同意“催眠是敏捷”。 那么大家反驳的到底是什么呢？ 是敏捷社区不接纳新事物、新想法么？以我这几年在社区的经验，答案是否定的。 大家真正反驳的是什么？ 如果我们仔细回看一下就会发现，这里面有一个非常明显的概念混淆，即催眠是敏捷。这是大家不能接受的。 敬畏知识 最后引用一位朋友的话，作为最后一节内容： 敬畏知识。 为什么要敬畏知识 知识是不断创造并积累的。我们需要敬畏知识有两大原因： 尊重概念的提出者（知识的源头） 不会误导他人（传播知识） 很显然，所有的概念都不是完美的，都会有相应的适用场景和改进的空间。那么如果概念有缺陷我该怎么办？我的做法是会找到概念提出者（或者最接近的人）进行讨论，交换彼此的想法。 如果我擅自在原概念上加入其它体系的知识并传播，就是在误导他人。这是作为知识工作者不应该有的态度。 如何敬畏知识 想要做到敬畏知识，有两个小窍门： 引用原概念，然后发表自己的观点 创建新概念，在原概念启发后可以有自己的知识体系 比如敏捷已经有敏捷宣言，那么我不会去修改敏捷宣言。而有可能创建新的宝宝说。 对于今天的分享，您有不同观点？欢迎回复留言讨论。
2017/3/29
articleCard.readMore理想与现实
题目的由来 这个题目是怎么来的呢？我在3月24日25日参加Bill的CSPO课程，一开始有一个大家讨论的问题是，“你认为产品成功的条件有哪些？（或项目）” 大家讨论的结果并不重要，重要的是在这个过程中大家开始讨论产品与项目的联系和区别。 以前我的理解是产品是长期存在的，而项目是（一个或多个）产品的一部分，即阶段性成果。 课程当中还有一段乔布斯早年的访谈视频片段（遗失的访谈）。其中讲的是乔布斯解释想法与产品实现之间的鸿沟，以及团队是如何一起协作的。 这段视频中给我一个启发，那就是“产品是理想的而项目是现实的”。即我们今天要讨论的标题“理想与现实”。 现状 德国人有一句名言是 生活是具体的。 这反应出在我们的生活中，多数事情是具体存在，即现实的。 而什么是理想呢？ 记得小学的时候老师总是会问，“你长大后的理想是什么？” 还记得很清楚，我的理想是当一名老师。虽然现在已经距离理想很遥远，但理想就是一个目标在前方指引着我。 因此 理想是遥远而触不可及的、长期目标； 现实是具体存在的、短期利益； 而我们的生活就是在理想和现实之间不断的进行取舍。最终就如图1所示，停留在理想和现实之间的某个地方。 图1 生活工作的现状 理想 既然我们认为理想是遥远而触不可及的、长期目标，那么如果我们一直盯着理想而完全忽视现实的话。如图2所示： 图2 只看理想而忽视现实 会有什么问题呢？ 常见的完美主义者，就属于这个状态。完美主义者并不是不好，而是陷入其中的话，会忽略现实，而错过了市场机会。 现实 现实是具体存在的、短期利益。如图3所示： 图3 注重现实而忽视理想 常见的现实主义者，属于这个状态。现实主义者的问题往往是忽视了我们应该打造完美的产品。 理想与现实 回到主题，我们来看一下在软件开发当中，理想与现实是如何结合的。 传统的瀑布式软件开发 在传统瀑布式软件开发中，认为软件开发就像在流水线生产一样（属于简单工作）。把软件开发当做理想来实现，所以到最后结果往往并不能让客户满意。（理想是丰满的，而现实是骨感的） Scrum软件开发 在Scrum敏捷软件开发框架中，非常好的平衡了理想与现实。产品（以及产品待办列表）代表了软件开发中的理想，这是团队的美好目标。而每个Sprint结束后潜在可交付的产品增量代表了现实，这是团队的现实情况。 就如图1所示，Scrum是完美地结合了理想与现实。既有理想的产品目标，又有现实的产出。 Scrum转型 Scrum框架本身也是完美的框架。在组织转型的过程中，作为敏捷教练要坚持Scrum框架（以及敏捷的价值观），不能妥协。作为现实的工作，在某些地方或多或少会有一些妥协，但是请谨记，此时的妥协只是临时方案。 最后，送给大家一句话。 Done is better than perfect. 让我们动手尝试一下吧。
2017/3/27
articleCard.readMoreScrum的定义
Scrum 的定义 Scrum: Scrum 是一个框架,在这个框架中人们可以解决复杂的适应性问题,同时也能高效并有创造性地交付尽可能高价值的产品。 Scrum 是: 轻量级的 容易理解的 难以精通的 自上世纪 90 年代初期以来,Scrum 就已经应用于管理复杂产品的开发。Scrum 不是开发产品的一种流程或一项技术,而是一个框架,在这个框架里可以应用各种流程和技术。 Scrum能使产品管理和开发实践的相对功效(relative efficacy)显现出来,以便进行改进。 Scrum 框架由 Scrum 团队及其相关的角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的,对Scrum的成功实施和运用都至关重要。 Scrum 的规则把事件、角色和工件组织在一起,管理着它们之间的关系和交互。Scrum 的规则会贯穿这份文档。 上面是摘自《Scrum指南》中文版的介绍，即Scrum的官方定义。这里面几个点需要格外强调： Scrum是一个框架 Scrum是一个框架，而不是一个流程，也不是一个方法，更不是一项技术。这里面有什么不同呢？框架指的是这些内容组成一个整体，不可裁剪或修改。一旦裁剪或修改，框架就不稳固，容易出问题。 我们可以看看采用Scrum的组织中，出问题的大多数情况是在我们这里需要裁剪一下Scrum而造成的。比如每日站会太浪费时间，能否一周开两次。团队看起来没什么需要改进的，回顾会是否可以取消？等等 如果把Scrum裁剪了，请不要说在采用Scrum。 解决复杂的适应性问题 Scrum最适合解决复杂问题，比如软件开发这类复杂问题。另外还有适应性问题，即强调灵活性，需要团队可以快速响应变化。这是敏捷的本质，可以参考之前的博文“为什么敏捷是Agile，而不是Cgile或其他词”。 更多的解读，大家可以参加CSM敏捷认证培训了解详情。 参考材料：Scrum指南
2017/3/25
articleCard.readMore为什么敏捷是Agile，而不是Cgile或其他词
很多人都知道敏捷，即Agile，也知道这个词是来自2001年的敏捷宣言。但你们知道为什么是Agile，而不是Cgile或其他的词吗？ 我们来看看Craig Larman是怎么说的。（敏捷宣言是17个轻量型软件业的先锋于2001年共同签署完成的。Craig Larman当年也被邀请参加，但由于种种原因未能出席） 你看到“敏捷”这个词，或者你的组织进行敏捷转型，你首先想到的是什么？ 你想到的是提高效率、生产率、降低成本和提高质量、提高可预测性、或完成项目计划吗？ 如果你想到的是上述内容，对不起，你想的不是敏捷。（那一定是假敏捷） 敏捷（Agile）这个词最初的含义就一个，是 Flexibility 灵活性 更多有关敏捷不是快的信息，可以参考我的博文“敏捷不是快” 当年大家是怎么选择敏捷（Agile）这个词呢？据称当时有两个提议： Adaptive 来自Jim Highsmith的提议，和 Agile 来自Mike Beedle的提议 为什么Agile会胜出呢？这里我们可以八卦一下。（原因是Adaptive Software Development已经由Jim H采用，如果大家都同意Adaptive，那么Jim就会抢占市场先机。所以……） Agile一词虽然由Mike提出，但他自己在这之前并没有采用并推广。据Mike自己说他是从一篇1992年的（名为“21世纪制造业企业策略”）文章中受到启发的。 I was at IBM when the formation of the Agile Consortium occurred – IBM was part of that consortium, so I had a copy of the 21st Century Manufacturing Enterprise Strategy, which was published in 1992, and already used the word “agile” to describe development and manufacturing.
2017/3/24
articleCard.readMore《在TOYOTA学到的只要纸1张的整理技术》读书笔记
《在TOYOTA学到的只要纸1张的整理技术》 作者：浅田卓 本书的核心 一句话，用一张纸整理思路。 适合场景 工作清单 会议（培训）记录 市场分析 新商品策划 一张纸文件的共通点 目的 现状 课题 对策 日程 如何用一张纸进行整理 第一步，将思考用的基础信息整理到文件内 第二步，将自己独有的思绪、归纳到文件内 第三步，文件的内容要传达、沟通的对象 讲概念的三板斧 Why，这个概念的目的是什么，有什么好处 What，这个概念是什么，听众想听什么 How，这个概念如何用到我的工作或生活中 举例子 如何用一张纸进行自我介绍 在一张A4纸上画出8个（或者16个）格子 在左上角的格子内写上自己的名字 30秒内迅速填满剩余格子（填写内容为你想到自己特点的关键词，即你想要介绍的方面。只写关键词即可） 格子之间找关联，相同类型的标识一下 排序，介绍的时候先说哪个部分，再说哪个内容 下图是工作坊中大家介绍的例子，大家自我介绍完后都觉得这样进行介绍太轻松了。 用一张纸进行自我介绍的示例图 为什么一张纸这么有效 最后这里我自己总结了一下为什么一张纸这种方式有效。因为这种方式它有效地帮助我们进行了思考的分类。 比如上述的例子主要分为三大步骤： 收集整理数据。这个步骤做的事情是发散，头脑风暴。目的是记录脑子里出现的所有和目的或主题相关的词。 思考、归纳、找出联系。这步做的是思考。在上一步的基础上，审视已有的关键词，找出它们的联系，进行深度思考。 做出决策。最后基于上面的思考，进行最后的决策。 有关于决策，也叫作选择，是一个很大的话题。下一次我想专门来聊一下选择这个事情。 下一个话题你期待吗？
2017/3/23
articleCard.readMore敏捷回顾最高指导原则--敏捷回顾工具箱
Norman Kerth 在《Project Retrospectives》一书中曾提到回顾会议的primary directive principles: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. 无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。 如何理解回顾会议最高指导原则 这句话至少有三层深意： 信任 对事不对人 发展的眼光 信任 人与人之间很重要的一层关系是信任。唯有信任，团队才是真正的团队；唯有信任，人与人之间的协作才能顺畅。在回顾会议中，第一个要传递的信息就是信任。管理者对于团队是信任的，相信团队每个成员都已全力以赴。团队成员之间也是互相信任的。我们在现有已知情况、个人的技术水平和能力、可用的资源下已经做到最好。 对事不对人 回顾会议的目的是帮助团队提高与改进工作的流程。在这个过程中，团队必然会碰到发生过的问题。那么针对每个问题，必须明确的一个原则是对事不对人。我们现在讨论这个问题，目的是能从这个问题洞察到更深层的原因以避免之后发生同样的问题。而不是为了羞辱一个人。作为引导师，需要密切关注会议中的氛围。一旦发生针对个人的行为，引导师需要立刻采取行动。根据行为的严重程度采取的应对方式不同，细节可以参考引导方面的书籍。 发展的眼光 指导原则中提到“无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况……”，这段话说明即使现在发现了问题，部分是由于个人技术水平和能力有限，那么给我们一个很好的启示是，团队现在某个方面技术水平和能力需要提高，即团队（或个人）总是有提高发展的空间。 如何使用回顾会议最高指导原则 我最常使用这个原则的方法是：每次回顾会议开始的时候，团队全体成员集体朗读一遍。确信大家都理解之后才进行下一个环节。 ————————————————————— 最后广告时间 – Scrum联盟的CSM敏捷认证课程 2017年4月16日-17日 上海 2017年4月24日-25日 深圳 2017年5月25日-26日 北京
2017/3/22
articleCard.readMore敏捷不是形容词！
阅读《技术人创业攻略》一书中，作者对Dave Thomas的访谈有如下一段话： 真相是，“敏捷并不存在”。它不是一种东西，不是一个名词。人们是把它当做一个名词开始用起来的，但是他们并不理解背后的含义。 “敏捷”不是一种东西，敏捷是一个形容词——它描述了一种东西。你可能有一个敏捷的团队或者一种敏捷的过程，但你却从来不是“敏捷”。 对于Dave的这个定义我并不认同。 首先敏捷是一个名词。作为名词的敏捷，它不是一个状态，而是一个完美目标。 敏捷不是一个状态，不是一个状态，不是一个状态！有不少公司在敏捷转型的时候认为，只要我们做到xyz，我们就是敏捷了！对不起，你们并没有敏捷，你们只是达到了一个新的状态。 而敏捷是一个完美目标。何为完美目标？完美目标，是一个永远无法达到的目标。是的，敏捷就是一个永远无法达到的目标。 敏捷是一个持续学习的过程。持续学习也是没有终点的，是一路上不断地持续地学习。因此前几天微信群有朋友问，有没有敏捷成熟度模型？我内心想说的是，不要用模型限制束缚了持续学习。 其次敏捷是一个动词。作为动词，敏捷的含义让我们感觉是快。这里往往有误解，认为敏捷就是效率高、速度快！ 敏捷不是速度快！！！请参考我之前的博文《敏捷不是快》 另外我对敏捷的定义是“一个持续学习的过程”。在这个定义中，也没有任何一个字眼说敏捷就是速度快、效率高！ 最后广告时间 – CSM敏捷认证课程 2017年4月16日-17日 上海 2017年4月24日-25日 深圳 2017年5月25日-26日 北京
2017/3/21
articleCard.readMoreLearning from Boston SA F2F sprint2 (EN)
Keywords: “double loop learning”, “retrospective”, “Scrum” What inspires me to think about double loop learning Scrum is double loop learning (1977 HBR) 1. Before going to Boston, I read a wonderful article from HBR (https://hbr.org/1977/09/double-loop-learning-in-organizations), which illustrates learning in organizations, aka named double loop learning. To explain it in a short sentence, e.g during our discussion (Boston SA F2F sprint2), we came up an item from product backlog, which is about ensuring core Scrum accurate in SA web content.
2017/3/5
articleCard.readMore敏捷软件开发绩效管理系列之度量指标列举
在上一篇文章中，我提到以下几点： 绩效管理（度量）的主要目的 度量指标的分类 在这篇文章中，将会展开描述度量指标，详述在软件开发中都有哪些度量指标。 注意：这只是一个度量指标清单，不要照本宣科全部采用（会累死的）。一般建议对于一个组织（或者团队）选用7个以内的指标就足够了。 为了评估公司对产品交付的支持 客户净推荐值（NPV）——推荐产品的客户数/客户样本数 系统稳定性——比如通讯系统的99.99999% 预测进度 燃尽图（故事点或工作小时数） 团队速率（每个迭代交付的故事点数） 提高质量，减少技术债务 生产系统的缺陷数量——发生在客户一侧、生产系统上的缺陷数量（很重要的统计数据） 内部测试发现的缺陷数量（或者说迭代内缺陷） 单元测试的代码覆盖率 违规代码数量（Sonar等静态代码检查） 评估过程的有效性和改进 迭代是否完成目标 是否有回顾会议（反思改进） 需求的周期时间（cycle time） 价值流图 商业效率 产品的整体周期时间 达到收支平衡的时间点（tipping point） 获利的时间 投资回报率（ROI） 现金流（组织内的任何需求都可以折现成$$） 收入增长 评估用户（c端） 每日新用户数 每日留存用户数 每日付费用户转化率 每日净推荐值 企业文化指标 容忍失败，并从中学习 创新意愿 特性团队的比例 下一篇，我将列举一个现实中的团队绩效评估例子，并进行解读。 以下为广告。近期BoB的CSM敏捷认证课程安排如下： 2017年3月16日17日 成都 https://yihuode.io/activities/404 2017年3月23日24日 北京 https://yihuode.io/activities/419 2017年4月16日17日 上海https://yihuode.io/activities/444 2017年4月24日25日 深圳 https://yihuode.io/activities/436
2017/2/24
articleCard.readMoreCertified ScrumMaster (CSM中文认证课) - 成都 3.16-3.17
最近的课程： 2017年3月23日24日 北京 https://yihuode.io/activities/419 2017年4月16日17日 上海https://yihuode.io/activities/444 2017年4月24日25日 深圳 https://yihuode.io/activities/436 价格：早鸟价：6300元（早鸟已满）；三人同行每人可享6000元；普通7000元 说明：京东员工、敏捷社区志愿者有特别折扣，详情联系讲师（邮件或微信） 课程简介 从2001年提出敏捷宣言至今已有十余年，敏捷不仅仅在国外发展势头很强劲，在中国也有越来越多的企业开始敏捷转型。一开始是外企把敏捷带入中国，目前国有企业、民营企业、私营企业以及初创企业都在或多或少的应用敏捷实践。越来越多的企业和公司认识到敏捷转型的重要性。敏捷不仅仅是一些方法或实践，更是一种心态的变化，也是一个新的旅程。 在本次课程中，学员不仅从实际操作的层面上掌握Scrum的运用技巧，学员还将学会如何避免Scrum实施过程中的一些常见问题。Scrum很简单，但要掌握其精髓却并非容易，讲师结合自己在企业内实施敏捷转型的实践经验和Scrum框架，通过案例与游戏介绍解释什么是Scrum以及为什么Scrum可以如此高效。课程中通过多个游戏，和穿插的实例、练习、讨论等让学员亲历Scrum的工作过程、领悟Scrum的内涵、掌握Scrum的精髓。你的工作方式的改变从这里开始。 课程特色 来自于大型外资企业和互联网行业的一线敏捷实践 内容全面深入，重在实践操作与应用，囊括了大量项目经验 通过游戏化的方式，让学员在课后可以立即启动自己的Scrum 学习目标 帮助学员学习理解Scrum的原则、方法、与实践经验 提升学员对Scrum，以及敏捷最新实践的理解 通过游戏化的方式，学会如何在组织内进行Scrum转型 主要收益 Certified ScrumMaster证书 Scrum联盟两年会员资格 Scrum实战培训手册1本 对Scrum转型有帮助的、有启发性的1G+视频 团队敏捷备忘录1份 PMI上可以申请的16PDU 适合人群 作为一名Scrum初学者，我可以系统地学习Scrum，了解Scrum背后的原理以及相关知识，以便为组织的Scrum转型打下基础。 作为一名管理者，我可以了解Scrum框架的工作方式，还可以从Bob那里学习组织转型的经验，以便引导我的组织开展Scrum转型，收获更大的价值。 作为一名传统项目经理，我可以看到Scrum是如何工作并生效的，以便更好得把Scrum应用到项目中。 课程大纲 模块1：敏捷与Scrum概述 模块2：Scrum角色 模块3：Scrum工件之产品列表及条目 模块4：敏捷估算与规划 模块5：Scrum会议 模块1：敏捷与Scrum概述 敏捷软件开发逐步地深入人心，但在敏捷转型的企业中，只有很少一部分可以做到持续不断地交付商业价值，使客户满意。相当数量的企业敏捷转型后，效果并不理想，然而问题在哪儿呢？本次工作坊将会从“道、法、术”的层面来解读敏捷，学员将不仅仅知道什么是敏捷，还会了解为什么需要敏捷，敏捷的核心是什么，敏捷会给企业带来什么好处。 Scrum作为敏捷软件开发的一种框架，很简单，但实现起来并不容易。本模块将会分析Scrum价值观，Scrum的基础以及Scrum的概述。 模块2：Scrum角色 Scrum中包含3个角色：ScrumMaster，产品负责人和开发团队。为什么是这3个角色，为什么没有项目经理，一线经理负责什么。这些问题将会在本模块进行解读。 2.1 开发团队 Scrum中的开发团队是自组织的、跨职能的团队，是小的团队，是蜂拥式的工作方式。如何组建这样的开发团队，如何能够激发开发团队的自主性，这个子模块会重点探讨开发团队相关的问题。 2.2 ScrumMaster ScrumMaster是一个全新的角色，他不是项目经理。在Scrum团队中ScrumMaster常常看起来很“闲”，没什么事情做。这是一种错觉，也是一种误解。ScrumMaster可以作为教练，辅导团队Scrum转型；ScrumMaster也可以作为牧羊犬，保护团队不受外界干扰，可以在Sprint内专注于完成Sprint目标；ScrumMaster还可以作为引导师，使团队的会议变得更聚焦、更简单；ScrumMaster还是变革大师，不仅帮助自己团队Scrum转型，还要帮助组织进行转型。 2.3 产品负责人 产品负责人负责最大化产品以及开发团队工作的价值。在Scrum中，通过什么工具，以什么方式，产品负责人可以完成上述的工作，以及产品负责人的职责是什么，将会在这个子模块进行探讨。 模块3：Scrum工件之产品列表和条目 产品列表是团队工作的输入，是至关重要的一环。好的产品列表是ODDE的。如何创建一个好的产品列表，如何拆分产品列表中的条目，都有哪些内容可以放在产品列表中，产品列表的一些常见臭味。以上这些话题将在这个模块中进行深入的探讨。 模块4：敏捷估算与规划 敏捷中的估算怎么做，需要细化到什么程度。敏捷宣言中提到“响应变化 高于 遵循计划”，那么在敏捷中是否还需要计划。敏捷中的规划都有哪些，分别是什么用处，在什么阶段使用。本模块主要讨论这样的一些主题。
2017/2/22
articleCard.readMoreCertified Scrum Master CSM课程介绍
专业敏捷培训 | 高质量敏捷咨询辅导
2017/2/16
articleCard.readMoreCertified Scrum Product Owner CSPO课程介绍
专业敏捷培训 | 高质量敏捷咨询辅导
2017/2/16
articleCard.readMoreLinsheng Ma 马林胜
专业敏捷培训 | 高质量敏捷咨询辅导
2017/2/16
articleCard.readMoreRemington Hu 胡家闳
专业敏捷培训 | 高质量敏捷咨询辅导
2017/2/16
articleCard.readMore专业敏捷培训 | 高质量敏捷咨询辅导 | Scrum培训
专业敏捷培训 | 高质量敏捷咨询辅导 | Certified Scrum Master | CSM
2017/2/16
articleCard.readMore权威的国际敏捷认证Certified Scrum Master (CSM)
Certified Scrum Master (CSM)是Scrum联盟的权威敏捷认证，全球认可的敏捷开发认证。全球拥有超过100万的敏捷认证会员。本文介绍什么是CSM，和其他敏捷认证的对比以及敏捷认证的常见问题。
2017/2/16
articleCard.readMore权威的国际敏捷认证Certified Scrum Master (CSM)考试流程
Certified Scrum Master (CSM)是Scrum联盟的权威敏捷认证，全球认可的敏捷开发认证。全球拥有超过100万的敏捷认证会员。本文介绍什么是CSM，和其他敏捷认证的对比以及敏捷认证的常见问题。
2017/2/16
articleCard.readMoreScrum点滴--敏捷之旅2016北京后记
作者：安宝平 微信ID: abp0616 Scrum 点滴 一直想把自己使用和学习Scrum的一点心得体会写出来，因为各种原因一直没有动手，（主要原因是懒）。这次参加完“敏捷之旅2016-北京”之后正好碰见个4天的圣诞假期，再不动手就说不过去了。 在现在项目中折腾了将近4年，经历了很多很多，也和其他公司一些人讨论过Scrum，在此期间自己产生过很多疑问，也了解到别人的一些疑问，发现曾经搞清楚的问题有了答案没有记录下来，过了阵子完全忘记了，或者说那些问题的答案逐渐在自己的意识中边缘化甚至消失。自己的“组织过程资产”正在缩水，这是件恐怖的事 。趁着还没大幅缩水的时候做个文字版的记录吧。（如下内容是“现在”这个时刻的记录，半年之后会变化很多，至少现在对于Scrum的理解相比半年之前已经变化很多了。现在先记着，等研究半年后再做个记录。） 先定几个基调，嘿嘿：） 工程师如果知道这么写代码会出bug他肯定不会这么写，基本没哪个工程师故意写出有bug的代码。 工作性质决定了工程师写的代码哪怕一个单词拼写错误都可能出现bug，不是说开发工程师比其他行业的工作人员更容易犯错，而是由工作本身决定。（一个职员写一封英文邮件，有点拼写错误一般不会出现问题）。 个人或者团队的表现好与不好更多的原因在于事业环境因素。如果只抓着个人或者团队的错误不放，很有可能是在舍本逐末\缘木求鱼。 关于工程师文化：大家所谈的工程师文化都是积极的、正面的、向上的。。。我觉得吧，这有点不客观。脱离客观一般会出问题。 Scrum反对教条主义，同时反对生搬硬套Scrum的要求。不要“只是因为Scrum没有明确地提到就假定某个实践是不准许或禁止的。” 想不出来以什么形式记录这些内容，就用了模拟问答的形式，自己感觉良好。哈哈。 Q（1）: 我对于 “敏捷”粗浅的理解？ A: a) 对于比较庞大的需求，相对于瀑布模式，在敏捷中每个迭代都交付庞大功能的小部分功能，而不是等到所有功能都开发完成之后再交付，这种更早、更快的持续交付就是敏捷，是交付层面的敏捷。 b) 为了保证每个迭代所交付的产出具有该有的质量，要对本迭代和之前迭代的所有交付做充分的测试，这些测试要在短时间内完成，人工测试难以完成，所以施行自动化测试（含单元测试、集成测试和页面交互的自动化测试）辅以人工测试。自动化测试速度比人工测试快，这是QC层面的敏捷。 引用某大咖的话“敏捷是一种心态：一种拥抱变化，拥抱学习的心态，敢于尝试，强调实战，快速反馈，适应环境和市场的变化。需要每个成员的紧密合作，需要积极融洽的团队氛围。” Q（2）：Scrum是什么？ A: 在我看来Scrum讲的是工作流程，职责分工，如何与他人合作。是爱德华•戴明博士的管理理论在软件开发这个行业中的具体体现。是适合于软件开发这种工作的项目管理工具。 Scrum的流程是框架，文化理念才是核心。 Q（3）: 为什么要实行敏捷（Scrum）和实行时要注意什么？ A: 每个公司（团队）情况不一样，这个要看出发点或者目的是什么。就怕没有太清晰的目标，同时对于敏捷（Scrum）不甚了解的情况下引入。这种情况下引入Scrum比较容易制造出一个变形的Scrum团队：稍微问一下就会发现，其实是挂着Scrum的“羊头”卖着自己的“狗肉”，各层面问题仍然存在同时还给Scrum安了一个“徒有其名”的罪名。 想实行Scrum之前自己不妨多花些时间想想为什么要改变原来的开发模式，再找个Scrum专家（比如我，哈哈~）交流下，自己对Scrum做个深入了解，看看自己能否接受Scrum及Scrum是否适合自己。 Q（4）: Scrum Master工作的意义（产出），如何衡量？看起来Scrum Master没有做看得见的工作，凭什么要给你开薪水？ A: 这个么。。要是开发团队没有什么问题， Scrum Master确实没太大的意义，我也这么认为。但…是……，如果开发团队有很多问题，比如产出bug量很多，每个开发工程师一周之内用于修bug的时间大于等于1天。这样的情况下Scrum Master如果能把工程师每周用于修bug的时间降到1小时之内，整个团队的效率至少是20%的提升吧。一个团队年度预算如果是500W。嗯，这个产出就比较容易计算了。同时引用某大咖的话“敏捷不仅是对工作的改变，更是精神面貌的改变。” Q（5）: 实行Scrum不需要对远期的需求做讨论（规划），只把当前几个迭代的需求讨论清楚就可以了？ A: 这个是对Scrum的误解！Scrum说的是不对远期需求做过细的讨论，但不是不讨论。比如: l 开发的是一个全新的大项目：在开始第一个迭代之前还是要做高层次的开发规划，比如项目有12个功能模块，要在1年之内完成开发，此时要做一个年度的planning meeting。先把12个模块的流程图做出来，有了逻辑关系就有了开发顺序，再评估每个模块需要的人力。对比现有人员，就会知道是否需要补充新的人员或者评估出年度内会不会需要加班。 l 在已有项目上做新功能开发：在年度之初做planning meeting也是有必要的。只是此时可能不需要画流程图而是根据业务、市场的需求排列需求的开发优先级。 个人认为应该加入到Scrum Master培训中的内容：对于大型项目、多个Scrum团队并行开发的情形要做高层次的年度、季度planning meeting和retrospective meeting。 Scrum强调对于远期的需求不做详细的分析，只对近期要开发的内容做具体的定义，需求的细化是渐进明细的。这里要注意，低层次的、细枝末节的需求可以渐进明细，但是中高层次的需求就不能渐进明细了。反而要像瀑布开发模式那样，在最初就把中高层次的需求定义清楚。即,除了迭代的planning meeting要做，还要做季度和年度的planning meeting，要注意的是，这个年度的planning meeting比迭代中的planning meeting粒度要大的多，绝不是瀑布模型中细致入微的开发计划。对于怎么做如果加个限定词，那就是“必须”、“不遗余力”，否则容易形成需求层面的技术债务。如果在设计系统阶段没有对扩展性，耦合性，系统性能等等这些方面做充分的考虑，等问题出现时再补救会很头疼。张小龙很得意的一件事就是微信从一个小程序到现在的庞然大物没有经历过重构。 Q（6）: 实行Scrum之后不需要写文档了？ A: 这也是对Scrum的一个误解。Scrum强调面对面的沟通，避免撰写详细规格说明书，但不等于完全不写任何文档。有些文档仍然要写，并且要求还不低。我们项目组对于核心功能、重要功能和复杂功能，要求开发工程师一定要写detail design。写完的detail design通过了tech lead的审阅才能开始写代码。在此之前有时还需要工程师写出functional design（功能设计文档），所写的functional design由product owner审阅，审阅通过说明工程师对于功能需求理解到位，detail design审阅通过说明工程师在技术实现上基本没有偏差，再之后进行的开发才不会出现大的偏差。这样的QA工作做的到位再交付给QC时才不会出现过多的问题。我们这里在没有单元测试、集成测试等自动化测试的加持下做到平均每个工程师每个月产生2个bug，很大的原因在于上述QA工作。（不是说自动化测试不需要，不是我们不想做自动化测试，这些由项目组之外的管理层决定。这么大的项目目前由于缺失自动化测试导致的一些问题已经暴漏出来了。）
2017/2/10
articleCard.readMore敏捷软件开发绩效管理系列之如何考核敏捷团队
敏捷度量以及绩效管理，敏捷团队的考核和敏捷团队度量一直是个难题。本文会从度量的目标开始，然后进一步阐述度量的指标有哪些。
2017/2/9
articleCard.readMoreBoB Jiang敏捷新闻 - 2017年01月
2017年第一篇BoB Jiang敏捷新闻稿。 马上要春节啦，再次BoB提前预祝各位敏捷小伙伴，阖家欢乐，身体健康！ 2017年开始，BoB Jiang敏捷新闻开始对外开放，征集敏捷相关新闻、观点、案例分析等稿子（包含但不限于以上类别）。如果您想成为BoB Jiang敏捷新闻编辑的一员，欢迎加我微信私聊。（有心人肯定可以找到我的微信哦） 内容大纲 新闻 社区 荐书 课程 新闻 -————————————— 2017年6月3日在越南岘港举办敏捷之旅全球大会，本次大会将会聚集全球各地2016敏捷之旅最佳话题。详情参考：https://conference.agile-world.com/ 社区 -————————————— 2017年Agile1001（敏捷一千零一夜）有更多的玩法。想要加入我们，可以点击链接查看2017的课程内容。www.hdb.com/party/fcopb.html 2月份Agile1001的活动如下： 2017年2月12日 北京 人脉构建 by 王泽一 2017年2月18日 上海 敏捷团队右脑训练工作坊 by 王伟 2017年2月18日 深圳 精益看板工作坊 by 李国柱 2017年2月25日 北京 精益创业（或待定） by 龚正 2017年2月25日 成都 一起来读书 by 张莹 荐书 -————————————— 《精要主义》这是我读过的最有共鸣的一本书。先说一下整本书的结构： Explore 探索 - 区分出最重要的少数和不重要的多数 Eliminate 排除 - 敢于说“不”，排除不重要的事情 Execute 执行 - 让做重要的事情变成习惯，很容易的执行。 把书中一些共鸣点列举一下： 1. 抽离 - 为思考和探索留出时间。在现在移动互联网时间，每个人每天都非常忙，一点点闲暇时间也被碎片信息所充斥。在这个现状下，尤其需要注意留出时间进行独立思考。作者举出了几个例子（请参考书），我也说一下我个人的感受。冥想（坐享） - 每天有15分钟什么都不想什么都不做，静静的放空自己，注意感受自己的思绪变化。在李笑来老师的得到专栏也有很好的讨论。在最近一个月的练习后，明显我可以更好的认识到自己的情绪变化。 2. 勇气 - 优雅的说不的艺术。一直以来我认为自己是个烂好人，别人求助的事情90%都会答应。读到这一段之后给我巨大的冲击。原来说不有这么多方式，而且即使说不，也不会破坏关系。建议老好人仔细阅读这一章节。（优雅说不的六大原则）
2017/1/25
articleCard.readMore我的2016-BoBJiang
我的2016是成长的一年，飞跃的一年，自己还是非常满意的。获得的证书如下： CST (Certified Scrum Trainer) - 我是中国北方第一位CST 北京邮电大学软件学院工程硕士 - 终于在截止日期之前完成了 既然2016是成长的一年，我想从四个角度来进行总结，即 听 说 读 写 听 今年听了大大小小10来个培训或大会，但其中只有如下几个很有收获： 自费听的2个工作坊（培训）：Leading Agile Organization by Pete Benhrens, Problem Solving Leadership by Jerry Weinberg and Esther Derby 公司组织的培训：水平思考 by Sally老师 在线课程：敏捷教练修炼之道 by Lyssa Adkins 大会：AHA小会，Global ScrumGathering Bengluru, Regional ScrumGathering Hangzhou 说 线下分享10+。分享话题有《回顾工具箱》《设计思维体验工作坊》《提升团队研发效率1倍不是神话》《影响地图体验》。分享的大会有ToP100，TiD，PMI Congress2016，厦门技术峰会，怒马线下活动，Agile1001线下活动，Global ScrumGathering Bengluru等。 线上分享10+。分享话题有《Scrum精髓》《精益看板》《敏捷领导力》《精益创业》《设计思维介绍》等 值得一提的是，今年第一次用英语进行分享。还是颇有一些挑战。 读 书籍：2016完整读过5本书，（有读书笔记）分别为《开放空间技术》《人人都能用英语》《重新定义工作》《把时间当做朋友》《即兴的智慧》另外还有一些零零散散的阅读记录，如《如何构建敏捷项目管理团队》《Scrum敏捷软件开发》《管理的未来》《给经理人的第一课》等 APP：最大的惊喜，发现了得到app，并订阅了《通往财富自由之路》专栏，借着这个平台发现李笑来老师很多的文字，如公众号，如免费书等等。 写 写博客50+。欢迎访问BoBJiang博客（https://bobjiang.com） BoBJiang敏捷新闻（月度）5篇 每日反思，2016年4月21日至今每天记录
2016/12/30
articleCard.readMoreBoB Jiang敏捷新闻 - 2016年12月
本篇是2016年最后一篇BoB Jiang敏捷新闻稿。2016年8月份开始，每月我都会发布一篇新闻稿，里面包含新闻、社区、荐书以及课程四个部分。如果您对敏捷新闻稿有什么建议、想法或意见，都欢迎回复邮件联系我。 2017年开始，BoB Jiang敏捷新闻开始对外开放，征集敏捷相关新闻、观点、案例分析等稿子（包含但不限于以上类别）。如果您想成为BoB Jiang敏捷新闻编辑的一员，欢迎加我微信私聊。（有心人肯定可以找到我的微信哦） 内容大纲 新闻 社区 荐书 课程 新闻 -————————————— 敏捷学习指南-带你从入门到深入。11月我发表于CSDN极客头条的一篇文章，敏捷从入门到深入一条可能的路。 社区 -————————————— 敏捷之旅陆续在国内多个城市举办，大部分都已经举行过了。 敏捷之旅北京也在12月18日完美收官，2017年Agile1001（敏捷一千零一夜）有更多的玩法。想要加入我们，可以点击链接查看2017的课程内容。www.hdb.com/party/fcopb.html 2017年1月15日 在北京，一起体验视觉记录吧。https://www.hdb.com/party/pze3b.html 2017年1月8日 在上海，设计思维体验工作坊。 https://www.hdb.com/party/xor3b.html 荐书 -————————————— 《Scrum敏捷软件开发》作者Mike Cohn。本书是Scrum敏捷转型的宝典，值得反复阅读。每次阅读都能再次从中受到一些启发。最近又翻开了这本书，两个点很有感受： 1. ADAPT模型，即改变需要如何发生（不仅限于Scrum转型） 1.1 Awareness 意识。意识到需要改变，可以通过度量数据，沟通达到目的 1.2 Desire 渴望。告诉团队有更好的方法，创造紧迫感或者造势等方法可以帮助实现目的 1.3 Ability 能力。提供辅导、培训（可以参考下面的课程）或共享信息等工具 1.4 Promote 推广。讲述成功的故事，吸引注意力，勾引兴趣。让更多的团队愿意接受改变 1.5 Transfer 传递。Scrum这个框架如何传递给公司其他部门，而不仅仅是IT部门自己玩 2. 自组织团队的CDE 2.1 Container 容器。自组织团队的边界在哪里，找到合适的范围（即容器） 2.2 Differentiator 差异。团队的差异是什么，扩大或减小差异对团队的影响是什么 2.3 Exchange 交换。信息在团队内是如何流动的，怎么样最大化信息流动，知识传递 课程 - Certified Scrum Master (CSM) 敏捷认证课程 -————————————— 2017年1月12日13日 成都 https://yihuode.io/activities/404 2017年3月23日24日 北京 https://yihuode.io/activities/419
2016/12/29
articleCard.readMore敏捷学习指南-带你从入门到深入
这是我11月发表在CSDN极客头条的文章。 什么是敏捷 敏捷（Agile）是一个全球性的运动，它正在改变我们的工作环境。敏捷这个词是2001年17位软件行业的大牛在一起讨论得出的（参见敏捷宣言），目前敏捷正在扩展到各行各业，而不是仅仅限于软件行。 敏捷到底是什么？我们看看下图（感谢Lynne Cazaly总结的40多种敏捷方法和框架）： 图1 40种敏捷方法和框架 上图所示，敏捷中有40多种方法和框架，超过70多种的具体实践，那么如何把这个概念介绍给他人呢？Cockburn博士（Alistair Cockburn）曾经是这么定义敏捷的： 敏捷是尽早频繁的交付商业价值。（Agile is to deliver business value early and frequently） 下面我们一起来看看，为什么我们要敏捷。 为什么要敏捷 了解敏捷之前，我们可以一起来看一下为什么我们要进行敏捷。敏捷可以帮助组织或公司来应对持续不断的变化，来应对这个VUCA（Volatile, Uncertain, Complex, Ambiguous）的世界。解决快速变化的唯一方法就是拥抱敏捷。由于软件变得越来越重要，敏捷也逐步变成企业转型的关键。 在敏捷的组织内， 自组织团队通过短期迭代（通常为1-3周）的方式快速交付客户价值。小团队都采用相同的节奏进行交付，因此大型的复杂产品开发也可以由多个小的自组织且端到端的特性团队来完成。敏捷是更聪明得工作，而不是更苦逼得工作。敏捷不是用更少的时间完成更多的工作，而是用更少的工作产生更多的客户价值。 敏捷入门 在我的培训课中，通常有学员问“ 一个人可不可以敏捷？” 我的回答是“必须可以”。下一个紧接着的问题就是“怎么做”？ 回答这个问题之前，我们一起回顾下敏捷的基础：透明、检视和调整。根据这三个基础，我们逐一来看怎么做。 透明。 人类大脑的美妙之处在于思考，而不是记忆。你是否有过某件物品突然之间就是找不到了？你是否碰到过有个人的名字就在嘴边，说不出来了？这就是我们通常说的大脑短路，忽然想不起来了。那么对于这些需要记忆的信息，我们需要做的是把它写下来，存储到一个便于查找的地方。比如我常用的几个工具是：笔、本子、印象笔记。笔和本子记录平时的各种想法、学习笔记等，还有一个专用的本子记录行程，印象笔记记录不错的网页和图片。这些信息对我来讲都是透明可视化了，我清楚地记得它们的位置。 检视。检视指的是不仅要记录，还要不断回过来看一下。做了一些尝试，记录一些内容，回过头来看看，通常会冒出一些新想法。这些新的想法也可以补充到笔记上去。 调整。做到透明和检视还不足够，还需要不断调整。这个调整有一个重要的动作指的是反思。回顾反思之前我做过的事情，哪些地方做的非常不错，哪些地方还可以提高，从中学到了什么，以后我可以做出哪些改变。 一旦掌握了上述的三个基础，个人开始就变得敏捷了，也变得更加开放和包容了。 我们最常说的敏捷，指的是团队级别的敏捷。透明，把团队的进度公开可视化。检视，团队不断回顾检视潜在可交付的产品增量。调整，团队不断反思如何改进工作方法和工作流程 同理，组织或者企业层面的敏捷也是按照同样的思路进行。 敏捷基础 敏捷的学习可以参考日本合气道的修炼之道，守破离。在学习敏捷之前，可以先选择一种敏捷方法或框架，如Scrum。然后守破离。守，指的是完全遵守Scrum框架的规定，不去进行调整或定制。要的是一丝不苟的练习。这个阶段至少6-10个迭代。破，可以对Scrum进行调整（打破框架），这个必须是在团队进行了大量的练习之后。一次一个地方进行调整试验，然后总结。然后再调整再总结。离，指的是根据实际情况，采用适合当时情况的措施，做出合适的应对。这个时候已经不是Scrum，也不是极限编程这样的方法或框架。 而是心中时刻留存的是敏捷的精髓，即敏捷宣言。以及敏捷的基础，透明、检视、调整。 常见的敏捷方法和实践包含：Scrum、极限编程、看板方法以及持续集成。 敏捷核心 敏捷核心的内容包含：敏捷宣言，以及敏捷原则，敏捷的心态（敏捷基础）和敏捷价值观。 敏捷进阶 敏捷入门之后，可以在这条路上继续前行。本部分一共包含三个方面：敏捷知识、教练知识、引导知识。上述每个方面的知识，从入门到精通至少需要七年时间（参见李笑来所著的《新生—七年就是一辈子》）。 专业知识：敏捷 图1所示的敏捷包罗万象，包含40多种方法，那么如何去学习敏捷专业知识是一个复杂的事情。建议可以从其中的1-2种方法或框架入手，如当前最流行的Scrum框架。Scrum入门可以参考官方提供的《Scrum指南》 ，想要全面学习Scrum，可以参考《Scrum精髓》。 学习的方法有很多种：如体验、观察，这些是基础的学习方法。举个例子，记得有一次去北戴河度假，有段时间流行自己蒸海鲜，我们买了一堆螃蟹回去。丈母娘自告奋勇帮忙洗海鲜，忽然我听到一声惨叫，哎哟哎哟。我赶忙跑过去看看发生了什么事情。原来丈母娘的大拇指被螃蟹给夹住了。仔细询问后得知，丈母娘把绑着螃蟹腿的皮筋解开了，想要放开洗。我相信丈母娘以后会非常小心螃蟹的钳子。这种学习的方式叫做体验，你亲身体验了就会记忆深刻。当时我老婆站在附近，她也看到这件事情。那么她也学到了要小心螃蟹钳子。这种学习叫做观察。对应到如何学习敏捷（具体说是Scrum），最好的方法是体验，在自己的团队中开始尝试采用Scrum。如果实在没有环境，也可以采用观察的方法。找一个正在采用Scrum的团队，去观察团队是怎么做的。 还有两种高级的学习方法是阅读和反思。阅读是拓展知识非常有效、非常快速的一种方式。世界上的事物有千千万万种，我们不会有那么多时间和精力一一进行体验。因此我们可以通过阅读优秀书籍来进行学习。拓宽自己的眼界和知识，这也是为什么敏捷当前包罗万象。另一种高级的学习方法是反思。曾子 曰：吾日三省吾身。每天都需要反思一下，那么反思怎么做，都需要反思什么。 对于个人反思，可以每天睡觉前花5-10分钟思考以下三个问题：今天我什么事情做得非常棒？今天有什么事情我可以做得更好？今天我学习了什么新的知识？ 对于团队或组织的反思，可以通过定期（如每周、每 月）组织回顾会议来实现。组织一次回顾会议可以参考这个步骤：预设会议基调，收集数据，激发灵感，决定做什么，总结收尾。具体每个步骤中的环节，可以参考《敏捷回顾》。 专业知识：教练 什么是教练？专业教练作为一个长期伙伴，旨在帮助客户成为生活和事业上的赢家。教练帮助他们提升个人表现，提高生活质量。教练经过专业的训练，来聆听，观察，并按客户个人需求而定制Coaching 方式。他们激发客户自身寻求解决办法和对策的能力，因为他们相信客户是生来就富于创意与智慧的。教练的职责是提供支持，以增强客户已有的技能，资源和创造力——（摘自百度百科）。 为什么学习敏捷，还需要学习教练知识。让我们一起看下敏捷宣言中的“个体与互动高于流程与工具”。这里个体与互动，强调的就是人以及人与人之间的互动（即团队）。如何激发个人表现，改善个 人的生活与工作，对于这些教练可以有很大的帮助作用。针对具体的教练技术和流派，在本文就不一一详述，有兴趣的朋友可以网络搜索一下，或者参考ICF（International Coach Federa）官方网站 。 专业知识：引导（facilitation） 什么是引导？引导是指通过创造他人积极参与，形成活跃氛围，从而达到预期成果的过程。这种成果可能简单到学习一项新技能，也可能复杂到解决一个跨组织和部门的复杂问题。总之，引导的作用就在于积极引导他人主动参与的互动过程。 在团队的日程工作中，团队会议是最常见的活动。那么如何形成活跃氛围，如何帮助团队高效组织会议，如何能够达成预期，如何解决跨部门的复杂问题等等。这些问题都可以通过引导来进行有效的解决。如《敏捷回顾》 一书中，就提到了很多引导的技巧。学习引导还可以参考《引导》这本书。引导进阶可以参考《引导的秘诀》。
2016/12/29
articleCard.readMoreCertified ScrumMaster (CSM中文认证课) - 北京
时间：2017年3月23日-24日 地点：北京，待定 最近的课程： 2017年1月12日13日 成都 https://yihuode.io/activities/404 2017年3月23日24日 北京 https://yihuode.io/activities/419 2017年5月25日26日 北京 https://yihuode.io/activities/420 价格：早鸟价：6300元（3月13日前有效）；三人同行每人可享6000元；普通7000元；费用包含报名费、考试费，不含差旅住宿费。 因名额限制，座位保留以付款为准。如因故无法参加可自行找人替换，如申请退款则退交款额50%，所以付款前慎重考虑。 说明：京东员工、敏捷社区志愿者有特别折扣，详情联系讲师（邮件或微信） 课程简介 从2001年提出敏捷宣言至今已有十余年，敏捷不仅仅在国外发展势头很强劲，在中国也有越来越多的企业开始敏捷转型。一开始是外企把敏捷带入中国，目前国有企业、民营企业、私营企业以及初创企业都在或多或少的应用敏捷实践。越来越多的企业和公司认识到敏捷转型的重要性。敏捷不仅仅是一些方法或实践，更是一种心态的变化，也是一个新的旅程。 在本次课程中，学员不仅从实际操作的层面上掌握Scrum的运用技巧，学员还将学会如何避免Scrum实施过程中的一些常见问题。Scrum很简单，但要掌握其精髓却并非容易，讲师结合自己在企业内实施敏捷转型的实践经验和Scrum框架，通过案例与游戏介绍解释什么是Scrum以及为什么Scrum可以如此高效。课程中通过多个游戏，和穿插的实例、练习、讨论等让学员亲历Scrum的工作过程、领悟Scrum的内涵、掌握Scrum的精髓。你的工作方式的改变从这里开始。 课程特色 来自于大型外资企业和互联网行业的一线敏捷实践 内容全面深入，重在实践操作与应用，囊括了大量项目经验 通过游戏化的方式，让学员在课后可以立即启动自己的Scrum 学习目标 帮助学员学习理解Scrum的原则、方法、与实践经验 提升学员对Scrum，以及敏捷最新实践的理解 通过游戏化的方式，学会如何在组织内进行Scrum转型 主要收益 Certified ScrumMaster证书 Scrum联盟两年会员资格 Scrum实战培训手册1本 对Scrum转型有帮助的、有启发性的1G+视频 团队敏捷备忘录1份 PMI上可以申请的16PDU 适合人群 作为一名Scrum初学者，我可以系统地学习Scrum，了解Scrum背后的原理以及相关知识，以便为组织的Scrum转型打下基础。 作为一名管理者，我可以了解Scrum框架的工作方式，还可以从Bob那里学习组织转型的经验，以便引导我的组织开展Scrum转型，收获更大的价值。 作为一名传统项目经理，我可以看到Scrum是如何工作并生效的，以便更好得把Scrum应用到项目中。 课程大纲 模块1：敏捷与Scrum概述 模块2：Scrum角色 模块3：Scrum工件之产品列表及条目 模块4：敏捷估算与规划 模块5：Scrum会议 模块1：敏捷与Scrum概述 敏捷软件开发逐步地深入人心，但在敏捷转型的企业中，只有很少一部分可以做到持续不断地交付商业价值，使客户满意。相当数量的企业敏捷转型后，效果并不理想，然而问题在哪儿呢？本次工作坊将会从“道、法、术”的层面来解读敏捷，学员将不仅仅知道什么是敏捷，还会了解为什么需要敏捷，敏捷的核心是什么，敏捷会给企业带来什么好处。 Scrum作为敏捷软件开发的一种框架，很简单，但实现起来并不容易。本模块将会分析Scrum价值观，Scrum的基础以及Scrum的概述。 模块2：Scrum角色 Scrum中包含3个角色：ScrumMaster，产品负责人和开发团队。为什么是这3个角色，为什么没有项目经理，一线经理负责什么。这些问题将会在本模块进行解读。 2.1 开发团队 Scrum中的开发团队是自组织的、跨职能的团队，是小的团队，是蜂拥式的工作方式。如何组建这样的开发团队，如何能够激发开发团队的自主性，这个子模块会重点探讨开发团队相关的问题。 2.2 ScrumMaster ScrumMaster是一个全新的角色，他不是项目经理。在Scrum团队中ScrumMaster常常看起来很“闲”，没什么事情做。这是一种错觉，也是一种误解。ScrumMaster可以作为教练，辅导团队Scrum转型；ScrumMaster也可以作为牧羊犬，保护团队不受外界干扰，可以在Sprint内专注于完成Sprint目标；ScrumMaster还可以作为引导师，使团队的会议变得更聚焦、更简单；ScrumMaster还是变革大师，不仅帮助自己团队Scrum转型，还要帮助组织进行转型。 2.3 产品负责人 产品负责人负责最大化产品以及开发团队工作的价值。在Scrum中，通过什么工具，以什么方式，产品负责人可以完成上述的工作，以及产品负责人的职责是什么，将会在这个子模块进行探讨。 模块3：Scrum工件之产品列表和条目 产品列表是团队工作的输入，是至关重要的一环。好的产品列表是ODDE的。如何创建一个好的产品列表，如何拆分产品列表中的条目，都有哪些内容可以放在产品列表中，产品列表的一些常见臭味。以上这些话题将在这个模块中进行深入的探讨。
2016/12/22
articleCard.readMoreCertified ScrumMaster (CSM中文认证课) - 上海
时间：2016年12月6日 - 7日 9:00-18:00 地点：上海市张江 - Stories(总部基地) 最近的课程：12月6日7日 上海 https://yihuode.io/activities/390 12月16日17日 北京 https://yihuode.io/activities/394 2017年1月12日13日 成都 https://yihuode.io/activities/404 价格：早鸟价：6300元（11月22日前有效）；三人同行可享6000元每人；普通7000元 说明：京东员工、敏捷社区志愿者有特别折扣，详情联系讲师（邮件或微信） 课程简介 从2001年提出敏捷宣言至今已有十余年，敏捷不仅仅在国外发展势头很强劲，在中国也有越来越多的企业开始敏捷转型。一开始是外企把敏捷带入中国，目前国有企业、民营企业、私营企业以及初创企业都在或多或少的应用敏捷实践。越来越多的企业和公司认识到敏捷转型的重要性。敏捷不仅仅是一些方法或实践，更是一种心态的变化，也是一个新的旅程。 在本次课程中，学员不仅从实际操作的层面上掌握Scrum的运用技巧，学员还将学会如何避免Scrum实施过程中的一些常见问题。Scrum很简单，但要掌握其精髓却并非容易，讲师结合自己在企业内实施敏捷转型的实践经验和Scrum框架，通过案例与游戏介绍解释什么是Scrum以及为什么Scrum可以如此高效。课程中通过多个游戏，和穿插的实例、练习、讨论等让学员亲历Scrum的工作过程、领悟Scrum的内涵、掌握Scrum的精髓。你的工作方式的改变从这里开始。 课程特色 来自于大型外资企业和互联网行业的一线敏捷实践 内容全面深入，重在实践操作与应用，囊括了大量项目经验 通过游戏化的方式，让学员在课后可以立即启动自己的Scrum 学习目标 帮助学员学习理解Scrum的原则、方法、与实践经验 提升学员对Scrum，以及敏捷最新实践的理解 通过游戏化的方式，学会如何在组织内进行Scrum转型 主要收益 Certified ScrumMaster证书 Scrum联盟两年会员资格 Scrum实战培训手册1本 对Scrum转型有帮助的、有启发性的1G+视频 团队敏捷备忘录1份 PMI上可以申请的16PDU 适合人群 作为一名Scrum初学者，我可以系统地学习Scrum，了解Scrum背后的原理以及相关知识，以便为组织的Scrum转型打下基础。 作为一名管理者，我可以了解Scrum框架的工作方式，还可以从Bob那里学习组织转型的经验，以便引导我的组织开展Scrum转型，收获更大的价值。 作为一名传统项目经理，我可以看到Scrum是如何工作并生效的，以便更好得把Scrum应用到项目中。 课程大纲 模块1：敏捷与Scrum概述 模块2：Scrum角色 模块3：Scrum工件之产品列表及条目 模块4：敏捷估算与规划 模块5：Scrum会议 模块1：敏捷与Scrum概述 敏捷软件开发逐步地深入人心，但在敏捷转型的企业中，只有很少一部分可以做到持续不断地交付商业价值，使客户满意。相当数量的企业敏捷转型后，效果并不理想，然而问题在哪儿呢？本次工作坊将会从“道、法、术”的层面来解读敏捷，学员将不仅仅知道什么是敏捷，还会了解为什么需要敏捷，敏捷的核心是什么，敏捷会给企业带来什么好处。 Scrum作为敏捷软件开发的一种框架，很简单，但实现起来并不容易。本模块将会分析Scrum价值观，Scrum的基础以及Scrum的概述。 模块2：Scrum角色 Scrum中包含3个角色：ScrumMaster，产品负责人和开发团队。为什么是这3个角色，为什么没有项目经理，一线经理负责什么。这些问题将会在本模块进行解读。 2.1 开发团队 Scrum中的开发团队是自组织的、跨职能的团队，是小的团队，是蜂拥式的工作方式。如何组建这样的开发团队，如何能够激发开发团队的自主性，这个子模块会重点探讨开发团队相关的问题。 2.2 ScrumMaster ScrumMaster是一个全新的角色，他不是项目经理。在Scrum团队中ScrumMaster常常看起来很“闲”，没什么事情做。这是一种错觉，也是一种误解。ScrumMaster可以作为教练，辅导团队Scrum转型；ScrumMaster也可以作为牧羊犬，保护团队不受外界干扰，可以在Sprint内专注于完成Sprint目标；ScrumMaster还可以作为引导师，使团队的会议变得更聚焦、更简单；ScrumMaster还是变革大师，不仅帮助自己团队Scrum转型，还要帮助组织进行转型。 2.3 产品负责人 产品负责人负责最大化产品以及开发团队工作的价值。在Scrum中，通过什么工具，以什么方式，产品负责人可以完成上述的工作，以及产品负责人的职责是什么，将会在这个子模块进行探讨。
2016/12/1
articleCard.readMoreBob Jiang敏捷新闻 - 2016年11月
这个月我参加了北京敏捷社区组织者聚会（以及部分讲师），有很多新面孔（很高兴社区有新人接班），也听到了一些有意思的分享。因此鼓励大家多走出去，和不同的人进行连接，可能有意想不到的结果哦。北京敏捷之旅的时间定在12月18日，具体信息请参看“社区”。 内容大纲 新闻 社区 荐书 课程 新闻 -————————————— 11月19日参加了厦门技术峰会，会上最有启发的两个演讲：1. 来自包季真的《新互联网时代下的连接与生态》，他提到移动互联网甚至物联网，玩的都是节点+连接，当够一定数量级之后，一定会很好玩，也会涌现出更多的创业机会。 2. 来自张婧的《闲谈用户评价的产品价值》，看似简单的用户评价，没有想到背后有那么多的考虑和设计。不仅从买家考虑，还要考虑卖家，有恶意买家，也有黑心卖家，更有空包刷单，如何设计才能把有价值的用户评价呈现出来，值得好好学习。 社区 -————————————— 敏捷之旅北京（敏捷、创新、未来）12月18日 - 报名链接：https://www.hdb.com/party/d2y7b.html 敏捷之旅天津 12月4日 - 报名链接 https://www.hdb.com/party/6lf7b 其他城市敏捷之旅的时间，请参考链接 https://jinshuju.net/f/Hgohvn/results 荐书 -————————————— 《开放空间科技–引导者手册》读书笔记 https://bobjiang.com/open-space-technology-reading/ 课程 - Certified Scrum Master (CSM) 敏捷认证课程 -————————————— 2016年12月6日-7日 上海 https://yihuode.io/activities/390 2016年12月16日-17日 北京 https://yihuode.io/activities/394 2016年12月22日-23日 成都 https://yihuode.io/activities/404 关于我 -————————————— 姜信宝 （Bob Jiang） 中国北方第一位CST（Certified Scrum Trainer） 资深敏捷教练、金牌讲师 旨在帮助企业改进工作方法以取得更好的商业价值。 Certified LeSS Practitioner，《Scrum精髓》的译者。 我的博客 https://www.bobjiang.com 邮件： bob@bobjiang.com 微信： bob_jiang_xinbao 电话： 13910939018
2016/11/24
articleCard.readMore开放空间技术-读书笔记
作者: 哈里森.欧文 出版社: 电子工业出版社 出版年: 2015-4-1 页数: 224 定价: CNY 48.00 装帧: 平装 ISBN: 9787121256653 开放空间是作者哈里森欧文在尝试过很多无聊的会议之后发现，其实每次会议的时候，在茶歇时间、参会人闲聊的时间会有更多的火花和碰撞，反而产出了很好的观点和结果。那么会议是否也可以像茶歇闲聊一样呢。这就诞生了开放空间技术（open space technology）。 我参加过很多大会（1000+人的那种），其实会议中的收获真不见得有多少，包括认真听分享也是这样。但会议中和新老朋友的交流反倒给了我很多的启发。所以下次大会如果我们碰到了，Say Hi哟。 转入正题，这本书中非常详尽地介绍了开放空间技术的基本方法和注意事项。比如为什么开场和结束要围成圆圈。 开放空间检查列表 适当性：我们是否应该选择开放空间来讨论这个问题，是否能够达到我们的目的。 主题：主题是否清楚、聚焦，并且提供足够的空间想象能力（要能够开放呀open） 邀请：是否提供足够的信息，比如时间、地点。是否可以唤起参会人的主动性。主动参与是开放空间最重要的一个注意事项，没有人是被强迫参与的。 时间：是否已经安排好足够的时间了。 空间：场地是否足够大，是否有平整的墙面，是否可以粘贴胶带。 饮食：茶歇安排在哪里，午饭怎么安排。 物料准备：胶带，马克笔，白板纸，报事贴 后勤安排：投影仪，场地方沟通等 开放空间的原则 四大原则 出席的人就是对的人（Whoever comes is the right people） 发生什么就是当时只能发生的事情（Whatever happens is the only thing that could have） 何时开始都是对的时间（Whenever it starts is the right time） 结束的时候就是结束了（When it’s over, it’s over） 一项法则 双脚法则 - 在会议进行中，任何人发现自己在某处没有学习也没有贡献时，他必须运用自己的双脚，走到某个自己更有生产力的地方。 蜜蜂和蝴蝶：运用双脚法则后，开放空间中出现了这两个角色，他们都是干什么的呢？大家猜一下也能知道的哦。不介绍了。
2016/11/23
articleCard.readMore敏捷之旅2016中国各城市时间一览表
敏捷之旅2016中国各城市时间表： https://jinshuju.net/f/Hgohvn/results 敏捷之旅北京 什么是敏捷之旅( agiletour) agiletour（以下称为敏捷之旅）是一个国际非盈利性组织，于2008年成立，总部位于法国。其目的是提供一个高效有趣的敏捷开发学习途径，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。它通过一系列的活动，在全球的范围内 极大推广敏捷 希望通过一系列活动，在每一个参与城市都对敏捷思想引发足够的关注，并形成一个敏捷开发的社区。 分享敏捷的愿景 敏捷在持续演进，希望在打开新的视点的同时也把我们对敏捷的理解和观点分享给整个敏捷社团 联合 在保持敏捷文化和自治的同时，在世界各个地区提倡和提升敏捷的领导力 支持 帮助同行，朋友和本地商业机构转向敏捷方法
2016/11/8
articleCard.readMore申请SEUs（Scrum Educational Units）参加Scrum Gathering
登录Scrum Alliance (https://scrumalliance.org) 右上角在“Settings”下拉菜单中点击“Dashboard” 在“Actions”下面点击“Add new SEU” 选择“Add an event”分类 选择Regional Scrum Gathering 在新页面中填写详细信息，如下图 点击最后的“Create SEU”按钮，完成！ 另外有一篇文章“参加敏捷社区活动如何申请SEU”可以参考。
2016/11/3
articleCard.readMoreBob Jiang敏捷新闻 - 2016年10月
又到了每月的敏捷新闻稿时间。10月份Bob有两件非常值得说的事情： 1. 参加Julia的学习设计与引导工作坊，自我感觉是打通了体验式学习设计的任督二脉。 2. 参加了ScrumGathering杭州，又见到很多老朋友，认识许多新朋友。 细节可以参看下面。 10月27日28日在北京的CSM敏捷认证课程还有少量名额，有兴趣的小伙伴可以点击报名 （https://yihuode.io/activities/357）。 内容大纲 新闻 社区 荐书 课程 新闻 -————————————— ScrumGathering杭州报道 - 这次RSG（Regional ScrumGathering）我收获最大的一句话“音乐家制作音乐的目标不是为了写出更多的音乐，而是为了音乐可以影响到更多的人。那么对于软件开发呢？”来自David Hussman的类比。更多RSG报道可以参考我的杭州RSG流水账 (https://bobjiang.com/scrumgathering-regional-hangzhou-2016/)。 学习设计与引导工作坊 - 学习是如何发生的，学习者有哪些类型，如何在培训中照顾到每一种类型的学习者，在课程中现场演练实操并且获得多个视角的反馈。语言文字很难表达课程的细节，有兴趣的朋友，可以约我单聊。 社区 -————————————— 北京敏捷之旅，今年将有全新的尝试，让我们拭目以待吧。目前北京敏捷之旅（12月18日）开始征集讲师，如果您有话题提交可以点击链接（https://jinshuju.net/f/H0DJLt）。 敏捷之旅在中国很多城市都在陆续筹备中，想了解其他城市的敏捷之旅举办时间，可以点击链接（https://jinshuju.net/f/Hgohvn/results）。想要得到更多信息，可以给我写信。 荐书 -————————————— 《重新定义工作》 - 本书的英文标题直译是“工作的未来”，即本书探讨的未来的工作和公司应该是什么样子的，未来的员工是什么样子的，以及作为公司（组织）和管理者如何吸引和管理新一代的员工。 本书也探讨了未来的组织结构，如去管理层、合弄制（Holacracy）、扁平化管理等，但明显篇幅不够，细节不足。另外作为一本科普书籍，也没有给出作为个人（或管理者、组织）如何应对未来的工作。 本书结构清晰，从三个维度来进行分析：员工、管理者和组织。更多可以点击链接（https://bobjiang.com/reading-the-future-of-work/）。 课程 -————————————— Certified ScrumMaster中文认证课程 - 11月17日18日 厦门 https://jinshuju.net/f/yoy02v 关于我 -————————————— 姜信宝 （Bob Jiang） 中国北方第一位CST（Certified Scrum Trainer） 资深敏捷教练、金牌讲师 旨在帮助企业改进工作方法以取得更好的商业价值。 Certified LeSS Practitioner，《Scrum精髓》的译者。 我的博客 https://www.bobjiang.com 邮件： bob@bobjiang.com 微信： bob_jiang_xinbao 电话： 13910939018
2016/10/24
articleCard.readMoreScrumGathering杭州记录
流水账和反思记录一篇。 2016年10月20日，携家眷一同从北京出发顺利抵达杭州。出发前约好大连的巩敏杰一共打车前往酒店（会场）。非常凑巧的是我们两个航班前后脚抵达，省去了彼此的等待时间。更让我意外的是敏杰同学不住在会场酒店，却把我们一家先送到。在此特别感谢一下！ 抵达酒店后发现舟师傅刚刚到达，深夜促膝长谈一番，回酒店休息啦。 10月21日，早饭约孟繁强一起，约两家家属一起出去玩。可能孩子岁数差异比较大，最后没成行。早饭后签到，实话说签到流程还是蛮顺利的，也可能是我签到的时间比较晚。就是签到环节领取发票，这个比较耽误时间，我果断决定等后面有时间过来取。 讲真，第一天大会只听了第一个Keynote（David Hussman）。非常喜欢他的一个类比。音乐家关注的不是写出更多的音乐，而是如何让自己的音乐影响力更大（更多的人喜欢）。 想一下我们的软件开发吧！今天（10月24日）是程序员节，尤其是在这样一个节日里，程序员们，管理者们，你们还在关注效率这件事情吗？还在关注写出更多的代码吗？需要转变思路啦。 另外Hussman还按照敏捷宣言的格式（xxx over yyy）提出了一番产品开发的宣言。如下： 上午后来和春山、大卫张、Bill等一起讨论中兴敏捷转型中的一些困惑。有很多的感触。尤其还学到了领导力相关的模型。（个人和组织层面看问题）更细节的信息，可以当面约聊哈。 下午约CSx一起商量下一届SG的事情，以及其他相关的Scrum联盟事宜。 多谢Ethan Huang介绍搜狗的美女金燕燕认识。不过貌似她的目的很明确。 Open Space环节，我提了一个话题，有钱有闲。可惜后来我先退出了。 晚上和老婆儿子一起品尝旁边的味庄，味道不错！赞一个！ 回去后，参与到品茶大会，Andy、黄哲、张燎原、杨瑞、飞哥、陈婧、Terry等。意外发现Terry是个段子手。。。 10月22日，ScrumGathering第二天，感谢组织者、志愿者、以及视觉团队。这个环节做得非常棒，要对这些幕后英雄给以肯定。 听了第一个keynote（David Anderson）。话题临时从taking Scrum implementation to next level with Kanban改为find your own agility path with Kanban。本来想看看Anderson如何把Scrum带到一个更高层面，有点小失望。 在他的演讲当中，讲的是敏捷很深层的道理，不涉及对错的问题。所以也没有get到多少。 然后“破裤衩”环节，有一些很有意思的演讲。比如Scrum和土马的碰撞；网易杭州研发中心项目管理部的实践；等等。这个环节相当挑战呀，每个人只有20张ppt，每张ppt只有20s，时间到了自动跳到下一张ppt。 下午讨论了一下《Large Scale Scrum》这本书的翻译工作，目前确定了初步分工，开始干活了。 总结一下，本次大会给我最大的体会是，场外的闲聊绝对值得。要和不同的人去碰撞。
2016/10/24
articleCard.readMore《Scrum精髓》试读版下载
编辑推荐: 上市以来雄踞亚马逊敏捷类畅销书榜首,热评如潮 Scrum 精髓,一点就通, 一本就够 揭示同类书不告诉你的主题和秘笈 适用于大多数敏捷过程的实用指南 适合团队成员、经理和执行负责人阅读的知识读本 如果想用 Scrum 来开发足以引爆流行的产品和服务,本书就是你梦寐以求的 完全参考。作为业内领先的敏捷教练和培训师,Kenneth Rubin 用通俗易懂的语 言和丰富的实例与我们分享他十多年的实践经验,诠释 Scrum 的价值观、原则 和实践,描述一些灵活、可行的方法帮助我们用好 Scrum。 针对 Scrum 新手和达人,本书从团队、产品和产品组合这三个层面来介绍、 澄清和深化 Scrum 的相关原则和应用。Rubin 曾帮助数百个组织成功应用 Scrum, 积累了相当丰富的实践经验和表达能力。作为这些经验和能力的结晶,本书图文 并茂,通过通俗易懂的描述和两百多幅图对 Scrum 进行了阐述,这些图采用的 是一种全新的视觉图标语言,用于描述 Scrum 的角色、工件和活动。 本书可以帮助团队成员、经理和执行主管了解 Scrum 常识,掌握可以拿来即 用的通用词汇表,充分攫取 Scrum 的潜力,最终实现优秀团队能够做到持续、 稳健发展的目标。 内容简介: 短短几年时间,Scrum 跃升为敏捷首选方法,在全球各地得以普遍应用。针 对如何用好、用巧这个看似简单的框架,本书以通俗易懂的语言、条理清晰的脉 络阐述和提炼出 Scrum 的精髓。全书共 4 部分 23 章,阐述了七大核心概念:Scrum 框架,敏捷原则,冲刺,需求和用户故事,产品订单,估算与速率,技术债;五 大角色:产品负责人,ScrumMaster,开发团队,Scrum 团队结构,经理:Scrum 规划原则及四大规划活动:多层次规划、产品组合规划、产品规划和长期规划; 冲刺四大活动:规划、执行、评审和回顾。 本书取自作者十多年的实践经验,对员工个体和管理层都具有重要的指导和 参考意义,可以帮助企业导入 Scrum 方法实现敏捷转型,从而在动态的商业环 境中以积极的心态拥抱变化,做出优秀、卓越的产品,成就创业、守业、常青基业。 《Scrum精髓》试读样章下载
2016/10/20
articleCard.readMore读书笔记《人人都能用英语》
人人都能用英语 学不明白就别学了，用得上就直接用好了——这就是方法。 — 李笑来 这本书是看完《把时间当做朋友》，看到李笑来的推荐后快速翻阅的。虽然短小，也有一些收获。 有一天，有个人在Twitter上提问： @maozhu1: @xiaolai 还请李老师用140字概括一下怎样才能学好英语？ 我回复说： 其实一个字就够了：“用”。 反思一下这个字“用”，对于敏捷何尝不是呢。我的培训课程中，经常有学员会问，如何实施敏捷，怎么做。如果都没有去“用”，何谈学好或用好呢？ 本书给我留下最深印象的是李笑来严谨的学习态度和方法。比如朗读，使用word作为词典工具，学习语法书，等等。 本书的后记，也着实让我震惊。一个人用两年时间，0基础开始用英语，雅思6.5分开始了留学。 所以，如果想要学好英语，那么开始用起来吧。 如果想要学好敏捷，也开始用起来吧。
2016/10/14
articleCard.readMore读书笔记《重新定义工作》
作者: 【美】Jacob Morgan 出版社: 人民邮电出版社 出版年: 2015-11-1 页数: 228 定价: CNY 49.00 装帧: 平装 ISBN: 9787115406446 本书的英文标题直译是“工作的未来”，即本书探讨的未来的工作和公司应该是什么样子的，未来的员工是什么样子的，以及作为公司（组织）和管理者如何吸引和管理新一代的员工。 本书也探讨了未来的组织结构，如去管理层、合弄制（Holacracy）、扁平化管理等，但明显篇幅不够，细节不足。另外作为一本科普书籍，也没有给出作为个人（或管理者、组织）如何应对未来的工作。 本书结构清晰，从三个维度来进行分析：员工、管理者和组织。 员工 书中阐述了未来员工的七大原则，他们是未来员工最有可能的工作方式，也是我们期待看到的方式： 有一个灵活的环境 可以定义自己的工作 共享信息 使用新的方式进行沟通和协作 有机会成为领导者 从知识型员工转变为学习型员工 自由地学习和指导他人 灵活的工作环境 灵活的工作环境，意味着任何时间、任何地点都可以进行工作。当下的互联网以及相关的协作工具，已经很好的支持了我们可以在任何时间，任何地点开展工作。但这个还不是关键，对于组织而言，最重要的是员工的工作结果，而不是员工的投入时间。 任何时间可以工作 任何地点可以工作 重视结果而不是投入 可以定义自己的工作 自定义工作分为三种类型： 基于话语权 基于自组织 基于选择 共享信息 共享信息有几个好处。对于贡献信息的员工，他可以知道自己的想法、建议和信息正在被上司和同事在进行讨论，会增加他的参与感。对公司而言，创造一个参与式的工作环境，还能增加创新的几率。 每个人都有机会成为领导者 领导不等于管理者，在当下的环境，只要你有独立思考，有内容，就可能成为一个有影响力的人，成为领导。在组织内部的员工也拥有同等的机会和能力。 新的沟通和协作方法 电子邮件俨然是当下互联网沟通和协作的主要方法，不过还是有很多其他更好的工具，比如Slack, Teambition, github等等。 从知识型员工转变为学习型员工 知识是不值钱的，而能够灵活运用知识才是无价的。现在搜索引擎能够为我们提供几乎所有的问题答案，而如何去运用他们，把这些知识内化为员工的能力，内化为组织的能力，这是关键的。 因此，员工如何可以转变为学习型的员工，对于组织如何打造学习型组织，都是很重要的。 管理者 未来的管理者不但要面对未来的员工，还要应对越来越快的互联网变化，因此对于未来的管理者需要具备十项原则： 管理者必须是领导者 从前方跟随（仆人领导，帮员工扫除障碍） 懂技术 以身作则 敢于示弱 主张共享和集体智慧 挑战传统，做一个“点火器” 实时赞赏和反馈 能够识别个人界线 适应未来的员工 组织 未来的组织是什么样子呢，雅各布描述未来组织的14项原则如下：
2016/10/14
articleCard.readMoreBob Jiang敏捷新闻稿 - 2016年9月
摘要： CSDN敏捷知识库出台啦 Scrum Gathering中国将在10月21日22日杭州举行 推荐书籍 - 李笑来的《把时间当做朋友》 推荐ScrumMaster认证课程，10月27日28日 北京，11月17日18日 厦门 内容大纲 新闻 社区 荐书 课程 新闻 -————————————— CSDN敏捷知识库出台啦！敏捷学习指南，敏捷知识一网打尽，敬请移步： https://lib.csdn.net/base/agile 社区 -————————————— Scrum Gathering中国，10月21日22日在杭州举办，目前（9月30日前）门票价格为3000元（原价3500元），十人团购享受九折，报名链接https://study.163.com/course/introduction/1003059019.htm#/courseDetail Scrum Gathering为敏捷实践者提供一次聚会的机会，分享关于Scrum和敏捷的实践以及知识，体验scrum 和敏捷的热情。在为期2天的盛会中，你将遇见志趣相投的Scrum实践者、讲师、教练和拥趸，你也将听到惊艳的主题演讲，参与开放空间活动，升华你对Scrum及敏捷的理解。 荐书 -————————————— 《把时间当做朋友》是我非常推荐的一本书。该书已经网络公开了，具体请移步：https://zhibimo.com/books/xiaolai/ba-shi-jian-dang-zuo-peng-you 从本书中最大的体会是，我被洗脑了，彻底的洗脑了。收获了几句非常简单的大实话： 做正确的事情远比正确得做事重要的多！方向正确了，爬得再慢也没关系。 积累。做任何事情没有窍门，如果说有的话，那就是积累。不管说刻意练习，还是死记硬背，就是一个努力积累。 现在就干（把这一刻立即编程伟大梦想的一部分） 课程 -————————————— Certified ScrumMaster中文认证课程 - 10月27日28日 北京 https://yihuode.io/activities/357 价格：早鸟价：6000元（10月15日前有效）；三人同行8折优惠（5600元）；普通7000元 说明：京东员工、敏捷社区志愿者有特别折扣，详情联系讲师 *********************************************************************** 学习设计与引导工作坊 - 10月11日12日北京 https://yihuode.io/activities/361 *********************************************************************** Certified ScrumMaster中文认证课程 - 11月17日18日 厦门 https://jinshuju.net/f/yoy02v 关于我 -————————————— 姜信宝 （Bob Jiang） 中国北方第一位CST（Certified Scrum Trainer）
2016/9/28
articleCard.readMore读书笔记《把时间当做朋友》
作者: 李笑来 出版社: 电子工业出版社 副标题: 运用心智获得解放 出版年: 2009-6 页数: 248 定价: 32.00元 装帧: 平装 ISBN: 9787121087097 这本书是参加京东大学的荐书活动的奖品得来的，很早之前听说过但一直没有读过。最近拿出来看了一遍有一些心得。最最重要的有2点： 积累 现在就干（把这一刻立即编程伟大梦想的一部分） 触动较大的还有两个方面： 学习的基本途径有：体验、试错、观察（这3个都是很基础的），以及阅读和反思（高级的学习途径）。 有关人脉，有两句话： 专心做可以提升自己的事情，学习并拥有更多、更好的技能，成为一个值得他人交往的人。 学会独善其身，以不给他人制造麻烦为美德，用自己的独立赢得尊重。 学习是ROI最高的行为，人的一生就是不断学习、不断思考的过程。
2016/9/13
articleCard.readMore敏捷新闻稿 - 201608
摘要： Scrum指南在7月份发布了最新版，增加了价值观的章节 Scrum Gathering中国将在10月21日22日杭州举行 推荐两本书 推荐ScrumMaster认证课程，9月23日24日上海 内容大纲 新闻 社区 荐书 课程 新闻 -————————————— 2016年7月11日，Scrum指南发布新版本，新增5个Scrum价值观：Focus（专注）, Courage（勇气）, Openness（开放）, Commitment（承诺）, Respect（尊重）。Scrum指南增加的原文如下： “当承诺、勇气、专注、开放和敬重五大价值观为 Scrum 团队所践行与内化时，Scrum 的透 明、检视和适应三大支柱成为现实，并且在每个人之间构建信任。Scrum 团队成员通过 Scrum 事件、角色和工件来学习和探索这些价值观。 Scrum 的成功应用取决于人们变得更为精通践行五项价值观。人们致力于实现 Scrum 团队 的目标。Scrum 团队成员有勇气去做正确的事并处理那些棘手的问题。每个人专注于 Sprint 和Scrum 团队目标的工作。Scrum 团队及其利益攸关者同意将所有工作和执行工作的挑战进行公开。Scrum 团队成员相互敬重，彼此成为更有能力和独立的人。” 社区 -————————————— Scrum Gathering中国，10月21日22日在杭州举办，目前（8月31日前）门票价格为2500元（原价3500元），报名链接https://scrumgathering.io/register.html Scrum Gathering为敏捷实践者提供一次聚会的机会，分享关于Scrum和敏捷的实践以及知识，体验scrum 和敏捷的热情。在为期2天的盛会中，你将遇见志趣相投的Scrum实践者、讲师、教练和拥趸，你也将听到惊艳的主题演讲，参与开放空间活动，升华你对Scrum及敏捷的理解。 荐书 -————————————— 1.《系统化思维导论》这本书买了一段时间，才翻出细细地来看。说实话，这本书没看懂，只能从整体上进行理解。问题是如何产生的，系统是什么，如何去观察系统，系统与行为之间的关系。这是我得到的几个问题，至于答案，还在不断摸索中。也希望有读过这本书的朋友，可以一起交流。欢迎给我写信。 2.《即兴的智慧》书中的十个练习看似简单，但是要做到不仅需要勇气，也需要不断地实践。练习一：Say Yes!；练习二：别准备；练习三：即刻行动；练习四：马上动手；练习五：尽力就好；练习六：细心观察；练习七：面对事实；练习八：别忘了目标；练习九：不要错过上帝的馈赠（类似欣赏式探询）；练习十：求求你，犯个错吧。详细的读书笔记参考：https://bobjiang.com/improv-wisdom-2015/ 课程 -————————————— Certified ScrumMaster中文认证课程 - 9月23日24日上海 https://yihuode.io/activities/346 价格：早鸟价：6000元（9月10日前有效）；三人同行8折优惠（5600元）；普通7000元 说明：京东员工、敏捷社区志愿者有特别折扣，详情联系讲师 关于我 -————————————— 姜信宝 （Bob Jiang） 资深敏捷教练，旨在帮助企业改进工作方法以取得更好的商业价值。 CST (Certified Scrum Trainer) ,《Scrum精髓》的译者。
2016/8/30
articleCard.readMore参加敏捷社区活动如何申请SEU
本文包含两部分内容： 什么是SEU 如何为参加敏捷社区活动申请SEU 什么是SEU（Scrum Educational Units） SEU是Scrum联盟推出的教育单元，为了表明完成某个教育培训或者符合特定学习目标的线下活动。SEU和实际花费的小时数是1：1的关系。SEU可以用来申请或更新CSP认证、CEC认证、CST认证。 SEU是持续学习的体现，是ScrumMaster在Scrum之旅上的写照。 SEU一共分为以下几个类别： 类别A：Scrum Gathering或Scrum联盟赞助的活动 该类别SEU申请无上限，一天的活动最大可以申请8个SEU。活动包含但不限于： 全球Scrum Gathering（目前1年三次，分别为北美、欧洲、亚洲） 地区性Scrum Gathering（中国杭州在2016年10月21日22日举办） Scrum联盟赞助的活动 Scrum Coaching Retreat Scrum CSP Retreat Scrum联盟会前或者会后工作坊 类别B：Scrum联盟的课程或辅导 该类别下的活动包括与CST,REP,CEC一起工作。一天的活动最大可以申请8个SEU。该类别可能包含： Scrum高级话题 CST提供的培训，如在线培训、录像、面对面的工作坊等 参加REP提供的活动 参加CEC、CTC的辅导 类别C：外部（不在Scrum联盟范围）的活动 该类别最多15个SEU。参加非Scrum联盟赞助活动，如敏捷会议、地区会议、非CST提供的各类培训（不同于类别B）。该类别更多是参与学习，而不是提供分享。 类别D：志愿者服务 该类别最多15个SEU。无偿提供专业Scrum服务。 类别E：独立学习 该类别最多15个SEU。可能包含： 准备Scrum演讲（准备时间） 写书、文章、博客 观看非CST主持的敏捷Scrum培训 读书（敏捷Scrum） 其他独立学习 类别F：其他合作学习 该类别最多15个SEU。可能包含： 基于某个学习目标的共同培训 参加非CST的在线培训 其他合作学习 参考链接（英文） 如何为参加敏捷社区活动申请SEU 敏捷社区活动，可以申请如上的类别C的SEU。登录Scrum联盟网站后，找到添加SEU的链接，然后如下图： 正文内容示例如下：
2016/8/24
articleCard.readMore管理的变革--互联网时代的管理入门
管理1.0 现代的管理起源于90年代初期，弗雷德里克 泰勒先生提出的《科学管理》理论，可以称之为管理1.0。 泰勒的科学管理 泰勒认为科学管理的根本目的是谋求最高劳动生产率，最高的工作效率是雇主和雇员达到共同富裕的基础，要达到最高的工作效率的重要手段是用科学化的、标准化的管理方法代替经验管理。泰勒认为最佳的管理方法是任务管理法，他在书中这样写道：广义地讲，对通常所采用的最佳管理模式可以这样下定义： 在这种管理体制下，工人们发挥最大程度的积极性；作为回报，则从他们的雇主那里取得某些特殊的刺激。这种管理模式将被称为“积极性加刺激性”的管理，或称任务管理，对之要作出比较。 – 摘自百度百科 泰勒对于管理的最大贡献在于把组织内的计划功能和执行功能分开。泰勒认为计划属于管理者的工作，应该由管理者来制定计划，把任务安排给执行者；而执行者只需要负责执行计划就可以。这在当时的环境下是一个巨大的进步，因为当时正是二战结束，工厂需要大量工人恢复生产，而大量的工人来自于农村或妇女（受教育的程度低）。因此计划工作需要由那些大学毕业的人来承担（即管理工作），而具体工作由执行者完成（即流水线工作）。 优势 把管理工作集中起来，执行者专注于执行，提高工作效率。适合于流水线业务。 劣势 面对当前越来越复杂的世界，尤其对于脑力工作者（知识工作者），很难把管理工作和执行工作完全分开。因此科学管理的前提条件已经不复存在。 管理2.0 1950年后，在管理领域陆续提出了如TQM（全面质量管理）、TOC（约束理论）以及6 Sigma等实践。这些实践的目的是为了提高组织的质量与绩效（效率），组织存在的目的就是取得第一名（某领域内）。 优势 组织的目标很明确，以业绩来度量，努力争取第一名。 劣势 忽略了组织中的人，更多是把人当做资源来看或使用。从而很难完全发挥人的潜能。 管理3.0 管理3.0中，把人当做人，每个人都是独立的，与众不同的。从90年代开始，众多的轻量型软件开发方法（后来发展出敏捷软件开发）开始更多强调人的作用。正如敏捷宣言中提到的： 个体与互动 高于 流程与工具 此时的组织更像是一个社区，每个人在其中都发挥最大的潜能。 优势 看重人的潜能和能力，调动人的积极主动性。 劣势 有时没有全局观。 下一代管理 下一代管理，是以敏捷为基础，除了认识到人的重要性之外，还要识别出整个生态系统。从全局出发，整体优化。 优势 把人真正解放出来，形成良性、可持续的发展关系。从而浮现出组织结构和工作流程。 劣势 非常理想化，需要更多的人来支持与落地。 最后欢迎大家提出不同的观点，可以通过左侧的二维码加我微信，一起交流。
2016/8/19
articleCard.readMore图书推荐：Invisible Influence - The Hidden forces that shape behavior
这本书是我的偶像Daniel Pink推荐的，看了一下介绍之后感觉非常认同。我认同的理由是： 想要说服别人，首先要和这个人建立链接。而快速建立链接的方法就是模仿对方，包含但不限于，模仿对方的肢体语言、行为、举止、甚至是说话的节奏等。 我想起来在TiD大会上古月的分享，分享中她放了一个视频（有关NLP心理学催眠），其中就有类似的一个模仿从而催眠的故事。 所以下次想要影响对方的时候，尝试一下模仿对方，而不仅仅是被动的听。 1. Invisible Influence: The Hidden Forces That Shape Behavior (Amazon, BN.com, IndieBound) by Jonah Berger IDEA: Peers are a powerful motivating force. Trying to push yourself to achieve something? Or encourage others to hit an important goal? Comparison to others, particularly those slightly ahead, increases motivation and performance. Even others’ mere presence can make us work faster and harder. Never exercise alone. ACTION: Want to have more influence?
2016/7/28
articleCard.readMore敏捷背后的心理学和教练技术--by古月
2016年7月17日参加TiD大会，今天很有幸听到了2个非常棒的分享。下面分享第一个，来自古月的分享，主题是《敏捷背后的心理学和教练技术》。这个分享主要分2部分：心理学+教练技术 心理学 一共谈到了4个心理学流派 精神分析疗法（弗洛伊德）–心理学的鼻祖。分析童年对于人的影响，以及人的类型性格分类（九型人格）。从而认识到人有不同的性格，不同性格会有不同的行为。（备注：认知是非常重要的，只有觉察了，才可能做出改变和调整） 行为疗法（华生）。刺激产生反应（Stimulation -> React）。行为都是由某种刺激产生的，即敏捷中常常说的，改变环境来改变团队行为，比如改变组织结构，开展每日站会等。 认知疗法（ABC理论、ABCDE治疗模式）。这个环节不是特别理解。 焦点解决短期治疗。这个是我亲历的教练提问模式。如下： 你之前有试过什么方法来改变吗？ 这种情况在什么时候让你感觉没那么糟糕呢？ 如果今天你回去以后，一觉醒来就发现奇迹出现了，今天困扰你的问题全都解决了！这时，你的生活会发生什么样的改变呢？ 如果给你现在的情况打个分，从1-10，10分最严重，你会打几分？ 你是怎么做才能使情况没有变得更加糟糕？ 教练技术 核心介绍了NLP教练技术。教练的三大原则： 不分析 不评判 不建议 原来这才是教练啊，真心虚呀，嘿嘿 这块最后记下来的只有那个练习了，并且由于没有正面观察到模特的表情，无感呢。。。 给我最大的感受，NLP就是读心术呀，哈哈 回头再找其他教练技术，继续深入学习了。
2016/7/17
articleCard.readMore新词汇Fachidiot-单领域专家
名词。对单个领域专家的贬义词，指的是该专家只是该领域专家，对多方面的问题只能采取狭隘的方法。 这个词是来自于德语，Fach的意思是专家。单个领域的专家我们不会叫他“傻子（idiot）”，不过这里指的是这个专家在其他领域像傻子一样，而只能精通一个领域。 Definition of fachidiot Noun. A derogatory term for a one-track specialist who is an expert in his field, but takes a blinkered approach to multi-faceted problems. Additional Information The word originates from the German but there is no suitable translation into English. A “one-track specialist” is not quite right because you would not call someone like that an “idiot”. The “fach” comes from the German for “subject”. Example: “Despite being an expert in horticulture, the manager came across as something of a fachidiot when dealing with translation issues.
2016/7/17
articleCard.readMore每日站会真的需要每天都开吗？#scrum-but
问题：最近有朋友咨询我，我们团队的每日站会，可不可以每周二、周四开？ 我的回答：不可以。 原因如下： 每日站会中，每个团队成员需要回答3个问题： 昨天我为团队达成Sprint目标做了什么 今天我准备如何帮助团队达成Sprint目标 有什么事情阻碍了我帮助团队达成Sprint目标 通过这3个问题，我们可以得到两个层面的信息： 团队内信息的透明度，整个团队的进度以及距离Sprint目标还有多远；同时是否存在障碍 每天团队都会得到反馈，并可以根据得到的反馈做出调整 如果不是每天开站会，那么就可能（1）团队内有些信息会隐藏。有的团队反映说团队小（比如4-5人）并且大家都坐在一起，随时都会沟通，没必要每日站会。而实际上团队内的沟通在多数情况下只有相关2-3人一起，而不是整个团队一起。因此每日站会还是非常有必要的（同步、透明化信息）；（2）团队错过最佳的调整机会。每日站会中，团队可以得知距离Sprint目标有多远，是否存在障碍或者问题。尤其存在障碍时，需要整个团队共同努力，来想办法解决。这不是说发现问题了只有在每日站会才说出来，而是发现问题马上暴露，但每日站会需要正式得让整个团队得知情况（一般这类信息容易在2-3人之间讨论）；（3）团队没有仪式感。每日站会可以让团队形成规律，每天固定时间、固定地点所有团队成员凑在一起同步信息和进度，很容易团队成员可以形成仪式感，这是一个非常重要的事情。 总之，每日站会，顾名思义是每天站着开的会议。如果不是这样，那么就不要叫每日站会。 如果您有不同意见或想法，欢迎和我交流沟通。扫我加微信哦~ 8月4日-8月5日Certified ScrumMaster (CSM中文认证课)，如果感兴趣也可以和我联系。
2016/7/11
articleCard.readMoreCertified ScrumMaster (CSM中文认证课)-20160804-20160805-北京
报名请点击链接 时间: 2016年8月4日 - 2016年8月5日 地点: 北京 价格：早鸟5600元，7月21日前有效；普通7000元 特别说明：京东员工、敏捷社区志愿者有特别折扣，详情联系讲师（邮件或微信） 以往学员是如何评价的 课程特色 在这次课程中，学员将从实际操作的层面上学习和掌握Scrum的运用技巧，学员将学会如何避免Scrum实施过程中的一些常见问题。Scrum很简单，但并非容易，讲师结合自己在企业内实施敏捷转型的实践经验和Scrum框架，通过案例与游戏介绍解释什么是Scrum以及为什么Scrum可以如此高效。课程中通过多个游戏，和穿插的实例、练习、讨论等让学员亲历Scrum的工作过程、领悟Scrum的内涵、掌握Scrum的精髓。你的工作方式的改变从这里开始。 内容全面、深入, 重在实际操作及运用囊括了大量项目论证过的经验 通过系列的练习和小组讨论，让学员在课后就能立即启动自己的Scrum 用Scrum的方式来讲Scrum框架 您将学到 什么样的项目更加适合于Scrum和敏捷开发 在Scrum和敏捷项目中如何控制风险 怎样组织产品Backlog，以及产品工作项的生命周期 如何能够保证您的项目有一个良好的开端 领导一个自组织的团队并不是一切都放手，如何能够激发团队自管理 您不仅收获一份Certified ScrumMaster证书，还将有： 1本Scrum实战培训手册 10+有启发的，对Scrum转型有帮助的视频 1份团队敏捷备忘录 Scrum联盟两年会员资格 PMI认可的14个PDU 培训大纲 Scrum的起源 Scrum概述 为什么用Scrum 敏捷宣言与原则 Scrum的价值 Scrum框架 Scrum角色及职责 产品负责人Product Owner Scrum Master 开发团队 Scrum活动 产品需求列表梳理Product backlog refinement Sprint计划会议 每日站会 Sprint审查会 Sprint回顾会 Scrum工件 Sprint Backlog 产品增量 产品需求列表Product backlog Scrum的误区 敏捷估算 Scrum实战演练 课程回顾总结 其他问题 可以给讲师写邮件（bobjiang@bobjiang.
2016/7/9
articleCard.readMoreCertified Scrum Trainer (CST)之旅
从想法到实现，我一共花了2年2个月的时间，所以要给自己一些时间。2014年4月我想成为一名CST（Certified Scrum Trainer），2016年6月29日11点终于实现了。先给自己撒花~ 内容大纲 时间线 什么是CST 如何申请CST 基本要求 申请材料 认证流程 我的收获 时间线 2014年4月 - 有了申请CST的想法 2015年1月 - 提交申请材料 2015年4月 - TAC成员初次评审材料失败 2016年1月 - 再次提交申请材料 2016年3月 - TAC成员初次评审通过，通知面试 2016年4月 - 因为签证，错过奥兰多的面试 2016年6月29日 - 班加罗尔ScrumGathering，通过面试 什么是CST CST，即Certified Scrum Trainer，是Scrum联盟（https://www.scrumalliance.org）颁发的认证培训师。具体的认证路径如下图： 要成为一名CST，首先要拿到以下三个认证（CSPO、CSM、CSD）中的一个，然后需要申请成为CSP，有了CSP之后才能申请CST。 如何申请CST 如果英文好的同学，建议查看Scrum联盟网站关于CST申请的消息。 CST是我经历过最严格的一次认证经历，通过认证本身这个过程我自己也确实提高了很多。下面列出的要求是认证的最低要求，但绝对不是说你符合要求即可（如果只是达到最低要求，基本100%挂掉）。需要做的是按照这个要求制定自己的计划，一步一步往这个目标前进。 基本要求 对于Scrum概念、实践和原则有着深刻的知识和理解 持有有效的CSP认证 作为ScrumMaster、产品负责人、团队成员，拥有大量的在组织内实现Scrum的一手经验 和现有CST一起合作教过Scrum，或者独立教过Scrum（非认证），需要符合以下要求 最少教过100个学员 最少教过10个多天的ScrumMaster培训（多天指的是连续2天或以上） 如果想要培训CSPO课程，需要有CSPO认证 申请材料 具体申请材料要求，可以查看Scrum联盟网站。 申请人签名 Scrum经验文档（描述自己作为ScrumMaster、产品负责人、团队成员的Scrum经验）。CST希望是有一手Scrum经验的人，并且在该文档中要体现出自己的收获和学习是什么，以及对于Scrum的理解 个人声明。文档中描述为什么Scrum鼓舞你，并且是什么激励你把这个分享给其他人；另外还要清楚回答为什么你要成为CST 课程材料 如果材料不是英语，需要翻译成英语 培训材料可以是一起创建的，或者是公司创建的。为了更好的评估你的Scrum知识，请指出哪部分是你开发的，哪些属于你的。我们想要通过你的材料看到你的知识，你的故事。我们需要了解你知道什么（而不是你公司或你同事的共同知识） 材料可能包含ppt、讲义、手册、练习簿、学习指南、课程计划、课程大纲、课堂练习描述、小组练习、学习目标或者其他。（提示：尽可能的复现出你的课程实际情况） 提交的材料应该可以复现出课堂中学员的体验 Scrum联盟正在把学习目标向Scrum指南靠拢，因此提交的课程材料目标完全符合Scrum指南 如果材料中有非Scrum的元素，必须标识出来，这样评审可以准确评估你对于Scrum框架的理解 如果你采用“training from the back of the room”或者其他参与式培训方法，确保提供下述材料（至少提供两类）： 课堂的学习产出 课堂照片、白板照片 课件描述、大纲，以及课程计划 课堂练习或活动 小组讨论提示 游戏结果（反思） 如果想法不是原创的，确保指出来源。使用商标或版权材料时，给出明确的提示。 主要考察ScrumMaster课程材料。通过CSTs后也可以提交CSPO申请材料 课程材料映射：下载CSM课程学习目标（如果同时要教CSPO，也要填写CSPO课程学习目标），明确指出你的培训材料哪部分覆盖了哪一个学习目标 培训经验 申请人必须提供信息，可以说明至少10个多天ScrumMaster培训课程（最少100个学员参与）。培训课程可以是： 非认证ScrumMaster课程 和其他CST一起教的CSM课程。申请人应该交付至少50%的课程内容才能算1次。 多天培训课程指的是连续2天或以上的培训。 和CST共同培训指南： 以往的申请人说，共同培训是一段宝贵的师徒经验 共同培训理想的方式是，链接CST社区。如果通过邮件很难获得共同培训的机会，考虑参加全球ScrumGathering。尤其可以参加Gathering并且在教练诊所注册。 多名CST的推荐信非常关键。CST的推荐为申请人提供了关于Scrum知识和培训能力的反馈。 Scrum联盟不建议为共同培训的机会或推荐信付费。 如果你符合Scrum经验申请需求，也有自己的ScrumMaster课程材料，希望寻找CST社区的共同培训的机会，可以发信到 support@scrumalliance.
2016/7/1
articleCard.readMore焦点式对话ORID感悟
5月17日非常有幸和2位引导大师（来自澳大利亚的Tom和David）一起交流。从David那里我更进一步学习了焦点式对话ORID这个方法（参考资料：什么是ORID）。以前我也多次运用这个方法，也算小有心得，但是对于R(反应性问题)和I(诠释性)的问题，感觉总是问不好。而且有的时候干脆跳过反应性或诠释性问题。这次David给我一个很有力的说法： R反应性问题，就好像是最后决策背后的能量，是助推器，使我们更加有动力去产生最后的决策。 I诠释性问题，是主题与个人之间产生链接，以及可能是参与者之间产生链接。而这种链接可以为我们带来意想不到的收获。 如果你想和我交流ORID焦点式对话，欢迎扫一扫我的微信： 最后送大家一个小例子，用来解释为什么焦点式对话是很自然的。 在课堂上，David把胶带扔给明伟老师，以下为明伟老师的反应和解释： 明伟老师看到胶带飞过来了 （O，客观事实） 明伟老师很淡定，面带微笑（R，反应） 明伟老师评估了一下风险，根据自己的经验做了了如下判断（I，诠释） 明伟老师伸手接胶带（D，决策） David用了一个小小的例子，就解释了ORID是一个很自然的对话过程。非常棒的例子！
2016/5/21
articleCard.readMore用户故事不等于软件需求
常常听到敏捷转型的团队提到，我们的一个迭代可以完成几个几个用户故事。那个故事怎么怎么样。那么什么是用户故事？用户故事就是软件需求吗？ 我们先来看一下什么是用户故事 什么是用户故事 用户故事指的是从用户的角度出发，来描述用户想要得到的功能。常见的格式为： 作为<某个用户>，我想要<功能>，以便于<实现某个价值> 用户故事需要采用日常用语或者用户听得懂的语言来描述，尤其注意避免使用晦涩的技术专用术语。 后来Ron Jefferies同学建议，好的用户故事符合3C原则：Card，Conversation，Confirmation；Jeff Patton同学，把这个3C继续扩充为5C（并总结为用户故事生命周期）：Card, Conversation, Confirmation, Construction, Consequence。 用户故事这个方法最开始的初衷是非常好的，希望技术人员（一般来说是研发人员）可以以用户的角度来思考问题。但在实际应用中，有些团队就会出现下面这样的例子： 作为一个系统的用户，我想要接口A，以便于和系统进行交互。 大家仔细体会，为什么这是一个反例？ 那么对于敏捷软件开发当中，需求是个什么东东，是不是都是用户故事呢？ 我的观点是，用户故事不是软件需求。 什么是软件需求 需求分析指的是在创建一个新的或改变一个系统或产品时，确定新系统的目的、范围、定义和功能时所要做的所有工作。（摘自wikipedia） 从上面的定义中可以看出，软件需求的定义更加广泛，而不仅仅是从用户的角度考虑用户所需要的功能。并且用户故事也只是展现功能的一种形式。 软件需求可能包含（但不限于）：功能（可以用用户故事展现）、原型、探索、技术改进、缺陷等。 功能的展现形式可以有（但不限于）：用户故事、用例、关键词短语. 因此，不要把用户故事当作是需求，需求有更大的定义和更多的展现形式。而用户故事是一个相对较小的概念。 用户故事不等于软件需求。 在敏捷当中是如何管理需求呢，请继续往下看。 敏捷需求是如何呈现与管理 对于敏捷转型的组织来讲，需求是首先要考虑的事情，这是团队的起点（输入点）。因此敏捷需求是很重要的一步，但这个在Scrum当中并未有很多的提及。 Scrum中有产品列表（Product Backlog）以及条目（Item）来管理需求，产品列表是如何产生的，条目何时是就绪的，何时是完成的。这些都需要在实践中不断摸索。 如何建立产品列表 用户故事地图是一个创建产品列表很好的方式。这是因为产品列表是一维的，排序的，这样很难找出相互有业务关联的条目。通过用户故事地图这种方式，可以很好的组织需求条目。如果你的组织需要这样的工作坊，也可以单独和我联系（jiangxb@gmail.com）。如下图： 如何把业务目标和需求条目进行关联 常常在平时的开发中，开发人员不清楚为什么要开发一个功能，或者是不了解背景，或者是不清楚业务目标。有一个非常有用的工具（影响地图）可以帮助团队。如果你的组织需要这样的工作坊，也可以单独和我联系（jiangxb@gmail.com）。例子如下图：
2016/4/28
articleCard.readMoreMy Working Guide inspired from Scrum
During teaching Scrum and coaching on Scrum, I summarized following working guide as a reference: Problem over Solution Note: The development team focus on how to build software, so normally development team focus on the solution. But the purpose for building software is to solve some specific problems, so we need to focus on the problem over focus on the solution. Because sometimes to solve problem we don’t need to build a feature, and we have an alternative solution.
2016/1/17
articleCard.readMore京东敏捷模型-更新篇
本文是整理我的分享《Scrum精髓-之京东敏捷之旅》，这个演讲分别在敏捷之旅厦门、敏捷之旅福州、敏捷之旅天津以及光环国际敏捷组织转型大会上分享过。 这个分享主要包含2大部分： 案例分享 京东敏捷模型 案例分享主要讲了2个，一个是活动提报团队；另一个是途牛融合团队。 在活动提报团队中，团队没有关注功能场景，两次未能真正满足业务方的需求。后来团队进行敏捷转型，并且引入需求发起方到团队中，随时能搞响应需求变化并可以澄清需求以及验收。最终第三次较好的完成了业务方的需求。并且得到了业务方和老刘的高度认可。 第二个案例是途牛融合。前期采用用户故事地图进行版本规划，拆分成3个迭代。另外把所有接口和风险都列出来，每天更新。最后做到了60天完成两大上市公司的融合。并且8.18促销当天，总收入同期增长10倍！ 从在京东内部敏捷辅导的案例当中，我总结了如下的京东敏捷模型（当心：所有的模型都是错误的，但是有用的） 一个核心：以价值为核心 没有工具或实践的模型都是耍流氓！ 那么以价值为核心的实践就是产品待办列表（Product Backlog）。好的产品待办列表是ODDE的，参考我之前写的博客。 基本点1：透明 软件开发当中很多信息都是不透明的，而信任的基础又是透明。那么首当其中就是要把可以透明的信息都展示出来，这里我首推物理板子，如上图左边。如果是异地团队（不推荐搞异地团队），可以考虑使用电子板工具，如上图右边（京东自主研发的lessw）。 基本点2：迭代 迭代还有一层意思就是重复的做事情，那么重复做事情必须有一个限制。对于Scrum，这个限制就是时间盒。 基本点3：反馈 敏捷的核心不是快，而是反馈快，参考我的博客。针对反馈的实践，敏捷当中有很多的工具和实践。 每日站会 采用最多的是每日站会，每天团队凑在一起，回答3个问题。这里的关键点不是汇报工作，而是团队作为一个整体同步信息，为了达成迭代目标而努力。 评审会议，而不是演示会议，参看我之前的博客。 基本点4：教练 如果上面说的实践您还不会，或者在练习的过程中碰到问题怎么办，那么这个时候就需要有教练-即敏捷教练。不论是内部教练或者是外部教练，都对敏捷转型会有很大的帮助。 下面是这个模型的总结，希望京东敏捷模型对你也有所启发。
2016/1/6
articleCard.readMore《即兴的智慧》读书笔记
即兴的智慧 作者: Patricia Ryan Madson 出版社: 华中科技大学出版社 原作名: Improv Wisdom 译者: 七印部落 出版年: 2014-1-1 页数: 236 定价: 39.00元 装帧: 精装 丛书: 七印部落翻译系列 ISBN: 9787560994635 第一部分 书中提到下面一段话，对我很有触动。 “一本游泳手册哪怕写的再详尽，在你真正跳下水之前，也毫无用处。学游泳首先要把自己泡在水里。学习即兴表演也是同样的道理。我的目标是将你推离泳池边舒适的躺椅，领着你爬上那高高的跳台，鼓励你跳入清澈的池水。退一步讲，哪怕你面对的是一片难以穿越的泥泞沼泽，即兴表演也能帮助你。” 此时我想起来艾森豪威尔将军的一句话“Plan is nothing, planning is everything.” 僵死的计划是一文不值的，而随时调整的规划是很关键的。随时调整是说在计划没有执行之前就不断调整么？我的理解是，不是的。 随时调整必须有支撑，有基础的。而随时调整的基础就是来自对行动的反馈。如果没有行动，就不会有行动的反馈，那么随时调整就变成一个空喊的口号。举一个具体的例子，很多团队都想进行敏捷转型，但有一些团队总是喊着口号或制定一些计划，我们要敏捷转型。而实际上就是没有行动，那么对这些团队来说，他们是不会体验到敏捷的好处的。现实当中，说敏捷不适合我们，常常也是出自他们的嘴里。 本书中一共给出了13个练习。每个练习都有一些小提示，即如何很好的完成这个练习。具有很好的实操性。 第一个练习：说Yes！ 记得参加Ken Rubin的CSM培训课时就有一个同样的练习。用Yes, But… 和 Yes, And…分别接龙。最后来说一下感受。可以看出来，yes but的句子，说着说着就木有然后了，而yes and常常会有一些惊喜的发现。 这个练习有2个提示：1. 选择一个亲密的朋友，在一周之内无论他做什么事情，都肯定他的想法。从他的每句话中寻找积极的一面。坚持下去看看什么结果。2. 选择一天，对所有的事情都说Yes，放下自己的成见，然后看看结果。 我会尝试一下这2个提示的。 第二个练习：别准备。 这个练习中也有两个小提示：1. 度过没有计划的一天，忘掉每天的例行计划，尝试去冒险，忘掉你所有的计划，跟着自己的心去发掘真正想做的事情并马上付诸行动。2. 集中注意力。当你注意到大脑开始计划时，不妨做个改变，想象一下你要把接下来的事情向中情局汇报。用你全部的注意力在当下的事情上，而不是接下来要发生的事情上。 第三个练习：即刻行动 试试看：选择一种行动，可以让你通过这种行动快速进入状态。（这种行动可以是打扫桌子，阅读，静坐等）养成习惯。每天固定一个时间段完成这个仪式，贵在坚持。 试试看：即刻行动。想一下你生命中最重要的五个地点，选择其中一个，放下所有的事情，即刻朝这个地点出发。 试试看：改变日常活动的地点。比如周例会改在室外，或者茶馆，咖啡厅等。给小伙伴一个惊喜。尝试不同的地点，找到你喜欢的地方。 第二部分 第四个练习：马上动手 不论有什么想法，马上付诸行动，动手先做一点点。书中举了一个例子，有一个家庭主妇，属于完美主义者。家里被孩子弄得一团糟，玩具散落一地，很多家务没有做，未完成的购物清单等等。“不知道从哪儿入手？”作者收到这个家庭主妇的求助之后，马上就来到她家里。和她一边聊天，一边帮忙收拾厨房，20分钟就收拾好了。接着收拾客厅，卧室。最后屋子里焕然一新。这个练习主要是针对完美主义者，作为完美主义者，会害怕事情做不好而迟迟不动手。实际上我们可以先做已经很清楚的小事情。 在组织这次京品书香的时候，是受到一个朋友的想法鼓励而行动的。同时也要非常感谢各位小伙伴的支持！你现在脑子里有什么想法？记录下来开始行动吧。 第五个练习：尽力就好 有时候全力以赴做事，事情结果不见得完美。也就是说付出与收获不一定成正比。凡事尽力就好。要接受事物的不完美状态，可以用下面的忠告来释放压力： 勇于犯错 接受平凡 保持平常心 这个试试看非常好：选择平常且实用的礼物。比如给朋友或者心爱的人送礼物。考虑一下日常都会用到的东西吧。（比如枕头，碗，日历，杯子，笔，拖鞋，毯子，咖啡等等）平时记录下来日常实用的物品，有助于挑选一份好礼物。
2016/1/4
articleCard.readMore伟大创意的诞生
知道这本书是我先看过这哥们（Steven Johnson）的TED视频（where good ideas come from）。很棒的视频，推荐大家有空可以去看看。本书的重点介绍了7种创新模式： 相邻可能 液态网络 缓慢的灵感 意外的收获 有益的错误 功能变异 开放式“堆叠”平台 我先来介绍前三个创新模式： 第一部分 相邻可能 书中举了一个例子，给我触动非常大。是说在19世纪，法国一位妇产科医生观察到每天医院都会有新生儿死去，尤其是那些早产的新生儿。这个问题困扰了她很久。一天下班后，她去医院旁边的公园散步，看到公园内有一个小鸡孵化器。突然她就冒出一个想法，针对于早产的新生儿是否也可以模仿小鸡孵化器，制作一个婴儿的专用设备。于是这位医生就找来公园负责小鸡孵化器的员工，并邀请他加入医院，最终在他们的合作下，开发出了第一款婴儿保温箱。 通过这个例子，给我一个启发。1. 针对工作中的难题或者问题，要随时都放在脑子里。2. 看到任何新鲜事物，都要想想看它是否能关联到现有的难题或问题上。 液态网络 第一次听到这个词，是在Daniel同学的演讲上。不过当时他的讲解貌似是说公司内的秘密网络，比如抽烟小聚会等。后来看这本书才真正理解什么是液态网络。书中举了一个很细致的例子，以水为例子。当水为液态的时候，是最有创新的动态和活力的，可以有很多种变形或者可能。可是如果为固态，即冰，就几乎是一成不变固定的，木有创新可言。而如果为气态，即水蒸气，则表现为混乱的，很难形成一定的规律。 那么对于企业创新也是同样的道理，在企业内部，信息的流动需要呈现一种液态的方式，可以以一种流畅稳定的方式流动。作为管理者是需要思考如何搭建一个有利于信息流动的环境的。 缓慢的灵感 缓慢的灵感书中用得例子较多，印象最深的一个是达尔文的进化论。就是说实际上在达尔文提出进化论之前很长一段时间内，他已经形成了类似的理论，只不过还没有完全成型。经过多次细小的证据佐证，以及不断的灵感刺激，最后才诞生了进化论。 针对这一点，我自己也略有体会。我在思考敏捷本质这个问题的时候，每次和别人聊天都能获得一些输入，也会结合我自己的想法进行震荡。多次碰撞融合之后，形成了我对于敏捷精髓的一套理解。那就是一个核心：以价值驱动为核心；四个基本点：透明、迭代、持续改进和教练。 第二部分 意外的收获 做梦 - 在梦中会有意想不到的收获，因此伟大的发明家在床头会放一个本子和笔。当梦中有发现的时候，迅速记录下来。 散步 - 每天固定散步1小时，散步的过程中放空自己。（冥想？） 收集 - 使用电子工具收集各种好想法，以及网络关于创新的文章。利用工具的打标签功能。 组织灵感的秘诀就是：建立能让灵感产生、传播、重组的信息网络。 有益的错误 伟大发明家犯下的错误，比普通人多得多。 如果没有错误，进化的脚步就会停滞不前，我们得到的只能是一系列完美的副本，没有任何变化。 功能变异 让完全不相关变成相关，从而可以引发相邻可能的思考。 城市的出现 咖啡馆模式，弱关系下的创意空间 苹果公司的壁垒模式 - iPod的研发过程。苹果公司将这种做法称为“并发”或“并行生产”。在产品开发周期内，所有团队（设计，制造，工程和销售）成员都会时不时聚在一起，集思广益，交换思想和解决方案，商讨最紧迫的问题。在一般情况下，这种交流是开放的，以接纳不同团队的观点。与传统的生产周期比，这个过程充满了争议，还会带来很多翻译难题，但却更为自由——精通不同学科的人可以进行更多的交流。 机会总是垂青于那些具备关联性思维的人 从一个领域转移到另外一个领域会迫使思维从新的角度思考，从而打破视野的盲点，或者从一门学科中借用一种工具来解决另一个学科的问题。 开放式“堆叠”平台 资源共享或者学术性的环境，可以通过大型、协作式的网络建立或改造创意。 托马斯杰斐逊谈创意本身的特质： 稳定的所有权是社会律法的一项馈赠，而且此项馈赠从社会发展的角度来说，算是晚了的。然而，有件事情倒是让人好奇，也就是说，倘若一个创意——某人的大脑瞬间的灵光一现，都可以被视为理所当然而且固定的财产，那么会出现什么样的情况呢？如果大自然所做的任何一件事比所有其他人的专属财产少一些影响，这种思考动力的行为可以称为一个创意，只要他远离别人，就是专属于他的；但此刻它被泄露了，迫使它成为了每一个人的财产，接受者无法不拥有它。它独特的特性也是这样，没有人拥有的更少，因为所有人都拥有全部。他从我这里接收到一个创意，同时并没有减少我所拥有的；就像他从我的蜡烛上点燃了他的蜡烛，接收到了光，并没有使我的蜡烛变暗。创意应该一个接一个地自由传遍世界，人类才能传播道德和教诲，才能有效地得到沟通，条件才能得到改善。它似乎一直是独特的，具有天然的仁慈。它像火一样照亮所有的地方，而没有减少一点亮度；它像空气一样移动，真实的存在着，无法约束，也不能占为己有。本质上，发明不能成为某人的财产。 杰斐逊指出，创意有偏向第四象限的自然倾向。创意的自然状态是流动、外溢、连接，是社会束缚了它们。
2016/1/4
articleCard.readMore合弄制-新型的组织结构？
在去年年底的时候，就听朋友介绍有一种新型的组织结构，名字是holacracy，最近看到有翻译成合弄制，也是蛮有趣的一件事情。 下面说一下我对这种组织结构的看法：在Scrum当中鼓励的是稳定的跨职能自组织团队，而在合弄制当中是根据事情自组织的圈子。两者之间有很多相似之处，不过最大的不同在于Scrum鼓励稳定的团队，而合弄制事情做完了，圈子就结束了。 为什么Scrum鼓励稳定的团队？因为在软件开发当中，很多的隐性知识是可以留存在团队中。而团队在一起才是最基本的作战单位。所以对于合弄制，目前我不是很看好，主要是对于软件开发工作，或者说产品开发工作，不一定很适合。 -——-以下为转发的关于合弄制的文章——– 本文首发创之网，转载请注明！ 硅谷上下开始流行一种新的管理思路：CEO 正式放弃在公司决策和管理中相当大部分的权利，并且赋予每一位员工充分的施行自己创意灵感的权利和足够的保护。这种新的管理思路名为「合弄制」(Holacracy) 。名字蛮奇怪，但是这种思路已经开始流行了有半年多了，而且不少硅谷优秀初创公司的创始人已经开始在自己的公司中施行合弄制的管理制度。 Twitter 联合创始人 Evan Williams 已经在自己的新创业公司 Medium 施行合弄制管理方法。而这种制度最开始由于 Zappos 的 CEO 谢家华宣布施行而获得了大量关注。Zappos——这家营收十亿美元，拥有 1500 名员工的鞋类电商公司，即将在今年年底之前完成向合弄制的管理制度转换。 我们不禁思考：给员工放权的程度这么高，能行吗？ 我们和谢家华以及高管团队、中层管理员工以及一线员工进行了多次访谈，并且在工作时间结束之后一同前往酒吧放松，了解了 Zappos 内部对于合弄制的期待和焦虑。 合弄制是什么？ 合弄制是一种着重于试验的委员会式管理方式。CEO 在这种管理模式中将正式放弃管理的权威，将权威转交给一个通过公司内部「宪法」成立的管理委员会，并转而承担重组公司员工小团队的职责。在合弄制之下，公司组织架构「去中心化」，公司员工重新自由组合成一个一个的小组。在小组当中，每人选择自己的职务和自己的目标。 那为什么会有管理者愿意施行这种方案？ 合弄制的支持者认为权力集中化的管理模式抹杀了公司的创新能力。 当下，事物变化的速度比十年前要快的多，幅度要夸张的多。因此我认为在这个年代，工作制度的弹性和适应性对于一家创新公司来说将会是其竞争力的来源。合弄制赋予了我们（Zappos）更大的弹性和适应性。 ——谢家华, CEO, Zappos 谢家华 得克萨斯州的一名管理人士 Stephen Courtright 认为，合弄制是未来公司机构决策制定走向「去管理人员化」的潮流的一部分。 不光是合弄制，传统公司的执行能力不断增强也是由于在内部形成了一个又一个小型作战团队。根据 Courtright 提供的数据，在上世纪 80 年代，财富 1000 企业中使用团队作为工作架构的企业仅占 20%。这个数字到了 90 年代，增加到了 50%，而在本世纪初，比例已经高达 80%。 特别是在一些竞争激烈的行业当中，合弄制能够在以 CEO 行使权力的代价下鼓励创新，进而促进发展。 合弄制是一种管理方法论，是一套专为适应性而推出的操作方式。 ——Evan Williams，CEO，Medium 但是，Boss 还是 Boss，对吧……？ 呃，还算是吧。CEO 可以单方面决定由谁来领导小团队，但显然在合弄制的形态下，这种行为会严重影响到新的团队对于 CEO 的信任，甚至整个新的决策机构。合弄制的法则就好像某些还在雏形阶段的君主立宪制国家的制度：君主依然「至高无上」，但如果他是一位开明的君主的话，他的国家运转会好很多。 也就是说，对于一个准备施行合弄制的公司 CEO 来说，他接下来唯一需要做出的单方面选择就是：独裁还是自制。
2015/12/29
articleCard.readMore敏捷不是快
最近听到有人说，敏捷就是快 - 快速发布，快速完成任务，甚至有人会问，这样快了以后质量有保障吗？那么我们先来看一下什么是敏捷。敏捷，英文是Agile，指的是敏捷软件开发。这里要特别感谢Alistair Cockburn博士给出的定义： Agile is to deliver business value early and frequently. 敏捷是尽早频繁地交付商业价值。 这里，我们没有看到“快”这样的描述。 所以说，敏捷（Agile）本来就没有说要快速交付。那么敏捷到底是什么，为什么总有人说敏捷快呢？ 我们一起来分析一下，假设有一个项目（比如说3个月的项目周期），分别由两个一样的团队（这里是假设，因为不存在两个完全一样的团队）来完成，（假设是A团队和B团队）A团队用传统的软件开发方法，B团队采用敏捷软件开发方法。那么由A团队来完成该项目，可能是3个月；B团队来完成该项目可能是3个月，或者更长。（这里忽略需求变更，人员变动等各种变数）这样看来敏捷软件开发并没有加速软件开发过程。那为什么那么多人说敏捷就是快，到底快在哪儿了？ 敏捷的本质是反馈快！ 我们还用上述的例子，如果是采用了传统软件开发方式，最终用户什么时间第一次看到我们开发出来的软件呢，基本上就是3个月后。而如果是采用了敏捷软件开发方法，最终用户最早可能是2周后（假设迭代周期是2周）就看到了软件。在用户看到软件并真正使用之后，他极有可能提出更多的反馈意见，也可能在使用过程中暴露出不同的问题。这些都是非常好的反馈，为后续迭代提供了方向（将会放入到产品待办列表中）。 除了反馈快，敏捷还有另外一个非常大的好处就是拥抱变化。在传统软件开发中，需求变化是非常难的（这里就不展开，想要了解的同学可以自行百度查询）。而在敏捷软件开发中，如果有需求变化了，直接就可以体现在产品待办列表中。唯一一点要求是不能改变当前迭代正在进行的工作！ 如果您对本文有不同观点，欢迎和我微信交流： 如果您想要了解Scrum入门资料，可以点这里；如果您需要敏捷培训，可以参考这里。
2015/12/27
articleCard.readMore组织创新之韩都衣舍
韩都衣舍，已经成为电商领域的一个神话，尤其是韩都衣舍的小组制。小编反思，对于传统行业如何进行组织创新。可以把传统行业拆分成两部分来看。 第一，产品设计（开发）阶段 第二，产品生产（工厂）阶段 在产品设计阶段（开发），因为这是一个极其复杂多变的过程，一定要尽可能缩短链条，使团队尽早获得各种反馈与支持。这也就是韩都衣舍小组制获得成功的关键。小组内3个角色各司其职，但又相互互补。 在产品生产阶段（工厂），反推工厂进行弹性生产，即低成本小批量生产。 本文转载自商业评论杂志。 -——————————— 2008年春天，济南，赵迎光带着7,000块钱开始了韩都衣舍的创业之路。2008年底，韩都衣舍销售额做到了300万元，2014年底，该数字已达到15亿元。更为难得的是，韩都衣舍在经营过程中找到了一套适合自身发展的管理模式，这便是在电商圈里被传得赫赫有名的“以小组制为核心的单品全程运营体系”，简称“小组制”。这一模式将传统的直线职能制打散、重组，即从设计师部、商品页面团队及对接生产、管理订单的部门中，各抽出1个人，3人组成1个小组，每个小组要对一款衣服的设计、营销、销售承担责任，相应的，小组提成也会根据毛利率、资金周转率计算。 韩都衣舍的小组制吸引了越来越多人的注意，甚至为许多企业的组织变革指明了一个方向。然而，韩都衣舍的单品全程运营体系的真正过人之处，不仅在于小组制及为小组制提供服务的公共部门，还在于韩都衣舍形成了过硬的服装品类管理能力。如果说，小组制更像是顺势而为的机制设计，那么，这种管理能力的发育，则更像回归本质的内功修炼，它会让企业走得更远。 韩都衣舍公司层面对各个子品牌、小组给予的支持与服务，是多品牌持续扩张更关键的原因，可分为三条线： 其一，按照规模和成长性划分，集团总经办下设两个组，品牌规划组与运营管理组。 品牌规划组的定位在于帮助品牌走完“从无到有”的过程，包括前期的市场调研、商标注册、知识产权保护，等等，从0到1,000万元，这个阶段的品牌都由该组来协助解决各种各样的问题。运营管理组的功能则在于“从小到大”，过了1,000万元以后，主要由该组提供支持。 其二，按照功能和合伙人的注意力划分，分成产品系和营销系。 赵迎光谈道：“其实我们每个子品牌也是由这两个部门组成的，每个子品牌的标配是15人，10个人做产品，5个人做营销，即产品团队加营销团队，光有产品没有用的，对于子品牌的孵化，营销能力很关键，你怎么提炼卖点，怎么做产品规划，这是需要一套能力的。” 其三，由企划部提供专业支持。 韩都衣舍的企划部有将近100个人，相对其2,600人的员工总数，这一比例是惊人的。企划部负责制订详细的企划案，以此把握品牌和品类的产品结构和销售节奏，为品牌规划组和运营管理组提供专业建议。商品是有生命周期的，在韩都衣舍，产品设计必须符合企划周期。 也就是说，韩都衣舍的小组制有两套并行不悖的逻辑，一是自下而上的人人创新，二是自上而下的中央控制。某种意义上，企划部相当于韩都的发改委与数据中心，根据历史数据，参考年度的波峰波谷节奏，制定目标，然后分解到小组。企划部的有效控制对整个供应链的协调工作是极为关键的，否则每年由小组制策动的数万款产品下单，没有节奏控制，纯粹找死。 韩都衣舍已经不再是一家互联网企业，从能力上看，它就是一家服装企业，这可以看作我们这个“互联网+”时代万众创新之下的一种保守。人们越来越能够理解：重要的不是互联网，而是通过互联网进一步回归商业的本质，最终留下来的将是那些更懂这门生意本质的企业，而非更懂互联网的企业。 （本案例全文刊登在《电商进化论》一书）
2015/12/25
articleCard.readMore如何成为引爆点 - 从成都敏捷之旅爆红话题的背后故事说起
本文是成都敏捷之旅组织者王友强，自我剖析，为什么我红了。 一觉醒来发现朋友圈被刷屏了，各个群里都在[有人@我], 定睛一看，原来是蚂蚁金服的于老师给我的总结作序并转发，引起了轰动，这下让我不能再低调的做个美男子了~躲一下飞过来的板砖先 截图时已经达到414阅读量！ 美国作家Malcolm Gladwell在《The Tipping Point》（译为《引爆点》）一书解释了许多难以理解的流行潮背后的原因，发现其中的因素，如果能够掌握这些因素，就可以轻易地推动起一个流行潮… 借助理论来分析下：首先是 个别人物法则 敏捷社区组织者们的人脉极广，他们的口碑相授是最快的传播途径！这是联系员效应 CEC/CSC，Agile Coaches，Architects等专家是业界权威，TA们的辅助分享能够大范围的引爆话题！这是内行效应 前方高能预警：大卫张林的评论在后面 GM，CTO最善于推销企业价值文化，技术风向等，他们的特殊能力就是在短时间交付信任！这是伟大的推销员 点赞的有同学，华人世界仅有的两位CSC（现为CEC），敏捷教练，Boss，同事，社区组织者，朋友和家人，感谢你们:) 注意头像上的外框 ~还没点赞的朋友还来得及:)以便把你们高亮出来~ 大家会发现，重点在于标题 - 友强是一个好同学，也许再过一段时间，对于大家只会记得的这个标题，这就是要说的第二点： 附着力法则 - 通过不断重复N遍的原则，把易于传播，记忆的内容安利到受众，使之久久不能遗忘~~~嗯，友强是一个好同学！引爆点还需要合适的环境，人为制造的条件，这就是第三点 环境威力法则引爆朋友圈，大概8:20发，提前和小伙伴们商议好，找一个时间点统一发出 持续的信息流和后续互动服务
2015/12/23
articleCard.readMore敏捷之旅天津站2015
什么是敏捷？ 敏捷是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求与技术的一种软件开发能力，更是一种灵活务实的思维方式。 它更强调开发团队与业务专家之间的紧密协作、面对面的沟通、快速反馈、频繁交付可用的软件版本、紧凑且自组织的团队、能适应需求变化的代码编写能力和团队组织结构，也更注重人的作用。 什么是敏捷之旅？ 敏捷之旅（Agile Tour）是每年一度的非营利性系列会议，总部位于法国，旨在把敏捷社区联系起来，提供一个高效、有趣的敏捷开发学习途径，在全球范围内推广敏捷开发思想和实践，帮助企业更好的实施敏捷。该系列会议分别在全球众多城市召开，从10月份开始到12月份结束前后历时数月。 如今已步入第8个年头，敏捷之旅目前正走向全球，并且获得了敏捷联盟（Agile Alliance）及Scrum联盟（Scrum Alliance）的支持。 敏捷之旅中国从成都站开始，到今年已经有20个城市举办过敏捷之旅，每年参会人数达到2000多人。天津敏捷之旅从2011年开始举办，已经走过了四个年头。（参与敏捷之旅可以在ScrumAlliance申请SEU学分） 为了共建天津本地的IT生态，天津谷歌开发者社区参与协办2015年敏捷之旅天津站活动，我们也期望通过本次活动能结识更多的本地经验丰富的朋友，听到更多本地的敏捷经验。 转载自 https://developers.google.com/events/5644954979794944/
2015/12/23
articleCard.readMore特性团队是敏捷必须的吗？
敏捷真的必须都是特性团队吗？ 在回答这个问题之前，我们先来一起看看团队的分类和各自的优缺点。目前大多数组织内团队为组件团队（Component Team），与之对应的就是特性团队（Feature Team）。 组建团队 优点：同一组件的人在一个团队内，组件的所有权清晰，大家的技能相同，便于交流沟通。 缺点：不利于产品交付，做出的组件与其他组件集成时可能出现问题。 特性团队 什么是特性团队？ Larmen和Vodde总结认为：理想的功能特性团队是应该跨职能、跨组件以及同地协作的。团队开发完整的用户功能，一般由6到8名具备通用技能、同时各具专长的人组成。换句话说，这就是我们Scrum团队的原型。 优点： 特性团队能更好地评估设计决策的影响 特性团队可以减少因为交接而引起的浪费 能确保总是让合适的人去讨论问题 组件团队给项目日程带来风险 能让大家关注于需要交付的功能特性 缺点： 【Larmen和Vodde】同时也指出了功能特性团队所面临的几大挑战…对于这点我非常感谢他们。常见的障碍包括…a.代码的并发访问、b.共享设计责任、c.学习新技能的难度以及d.公司组织结构。他们认为：通过一些现代的工具，这些挑战还是能被克服的…但这需要时间。 最后该回答题目了，那么特性团队是否是必须的？ 答案是取决于所在的组织环境，是的，虽然这个答案不是你想要的，但我只能给出这个答案。 我个人是倾向于特性团队，为什么，上面也已经说了很多好处。 我认为最重要的一个原因是，效果大于效率，也就是说作为一个团队，我们要看一下最后的产出（效果）是什么，而不是看团队的工作效率有多高。 最后我们一起来看一下组件团队和特性团队的对比图。（来自Craig Larmen和Bas Vodde）
2015/12/21
articleCard.readMore京东敏捷模型
本文开篇引用《管理3.0》里的一句话： 所有模型都是错误的，但都有用。 以下是我在京东研发实践总结的敏捷模型（或者叫模式），供敏捷爱好者参考。 该模型的名字是“一个核心，四个基本点” 一个核心是以价值为核心。 四个基本点分别为：透明、迭代、反馈和教练。 不给工具的模型都是耍流氓！ --引用自某人 下面分别介绍一下该模型当中用到的工具。 以价值为核心 – 工具实践是产品列表，详细介绍请点击。 基本点一（透明） – 工具实践是任务板。对于开始敏捷转型的团队，尤其推荐使用物理的任务板。 基本点二（迭代） – 工具实践是Sprint。在Scrum中，最重要的核心是1-3周的时间盒限制的Sprint。 基本点三（反馈） – 工具实践是每日站会、Sprint评审会、Sprint回顾会。 基本点四（教练） – 进行敏捷转型的关键在于，有人了解真正的敏捷是什么。那么不管内部教练还是外部教练，所起到的作用就在于此了。 最后总结为： 如果您想要了解细节，可以和我联系： 如果您需要敏捷培训，可以参考这里。
2015/12/19
articleCard.readMore敏捷软件开发工具大全
我们一起来看一下敏捷团队可能用到的工具。 如果说支持敏捷软件开发（比如Scrum）的工具，一般有如下几类： 1. 大型（全流程，相对笨重）- Rally，IBM Rational Team Concert, 微软TFS， 2. 中型（一般只解决某个流程，比如需求管理，简单的缺陷跟踪） - Jira，VersionOne 3. 小型（团队协作工具） - trello, teambition, slack, google doc, 4. 特定工具 - 比如持续集成Jenkins，代码静态检查Sona, findbugs，代码管理git Jira (母公司Atlassian已经上市） - 简单易用的Scrum、看板工具，而且有很多插件。 trello - 快速拖动，灵活设置，个人非常喜欢的一款工具。好几个个人项目都在这上面，包括《Scrum精髓》翻译。 teambition - 个人用过的最好用的团队协作工具，比起tower, worktile好用的不是一点半点。 slack - 即时消息工具，方便的创建不同的频道。另外集成了常见的团队协作工具，比如github, twitter,dropbox, asana等。 google doc - 最好用的在线文档工具，没有之一 jenkins - 好用的持续集成工具，如果要在线持续集成，并且使用了github，可以试试travis
2015/12/19
articleCard.readMore连海盗都震惊了！我们居然做到了27‰的付费转化率！
电子商务的转化率只有5‰左右，而我们做到了27‰的付费转化率！这是一个什么牛逼产品？它就是北京敏捷社区护照（下文简称护照 - 可以用来参加全部2016年北京敏捷社区组织的线下工作坊），一起来看看这是如何实现的吧。 第一步 10月10日，不到一天时间拉了400人微信群，最终聚集了550人的“敏捷之旅北京众筹群” 第二步 针对敏捷之旅的参会者，设计众筹方案。护照只有参与500元和1000元档位的众筹才可以获得。众筹结束时，有4个人购买了护照 第三步 12月1日发布了2016年的课程计划，并限时一周限额15个名额，最终11人购买了护照 在这整个过程中，我们参考使用的模型是来自Dave McClure的海盗指标（AARRR）。 越来越多的创业公司开始使用海盗指标 – AARRR，作为新产品分析基础和罗盘，指导创业探索的方向。而AARRR最早来自于Dave McClure的著名分享，他提出了创业公司赢得客户的五个阶段： 获取(Acquisition) 激活(Activation) 留存(Retention) 推荐(Referral) 收入(Revenue)。 作为500Startups的联合创始人和投资人，Dave见过太多的创业公司，他认为作为创业公司的CEO，其实只要关注这5个指标就可以了。这五个指标呈漏斗状。 1.获取(Acquisition) 什么是获取 获取意味着潜在用户首次接触到产品，比如访问了我们的首页，或者点击了我们的邮件。潜在用户可能来自于很多的渠道，比如SEO, 邮件、社交网络、电视广告等等。这个时候应该关注有那些给我们带来最大量潜在客户的渠道、那些成本低的渠道以及那些转化率高的渠道。 我们做了什么 上述第一步，先把对敏捷之旅有兴趣的朋友聚集在一起。而这些人也是护照的潜在受益者。 2.激活(Activation) 什么是激活 激活意味着用户开始认真地使用我们的产品，比如至少使用了一个功能，变成付费客户等。只有用户真正花时间体验了产品，才会投入金钱变成付费客户。通常要对产品做很多次迭代以及A/B测试来提高激活率。 我们做了什么 敏捷之旅2015北京站是我们的第一次活动，这次活动的详情请点击原文。在第一次活动结束时，已经有4人购买了护照。 3.留存(Retention) 什么是留存 当付费用户越来越多，关注点应该放在如何让客户经常使用产品的功能。一些留存指标的例子，比如：至少生成5张Invoice，经常来访问Dashboard等等。这个阶段应该关注与如何勾引用户继续使用产品。 我们做了什么 为了留住付费用户，我们开始设计2016年整体的课程计划。并于一周内进行了发布。2016课程计划如下： 2016年北京敏捷社区拟定的每月分享话题如下（使用护照可以免费参加2016全年活动） 1月 - 用户故事地图 2月 - 影响地图 3月 - 从想法到靠谱 4月 - 敏捷需求工作坊 5月 - 产品列表梳理工作坊 6月 - 引导的秘密 7月 - 视觉记录 8月 - 实例化需求
2015/12/18
articleCard.readMore创新牛人榜-伊隆马斯克
创新牛人榜是一系列博客，在这一系列博客中，小编将介绍在创新史上很牛逼的那些人，以及他们的伟大事迹。 今天来跟大家介绍一位小编的偶像，颜值超高的帅哥，伊隆马斯克（Elon Musk）。只说人名，很多人还是无感。没关系，下面小编列举几个公司名字看看你听说过没有。特斯拉（Tesla），贝宝（Paypal），Zip2, X.com, SpaceX（火箭发射）, SolarCity（新能源）, Hyperloop。对于一般人来说，如果能创立上面的任何一家公司，肯定都是无比自豪的事情，而Elon参与并主导了以上所列公司的创立。Elon Musk 涉及的领域还包括： 汽车 太空技术 太阳能 电池等储能技术 卫星 快速轨道交通 外星球殖民 等等 为什么 Elon Musk 这么猛？ 他如何跨学科学习的？他的思维模式是怎样的？ 1. 他极度勤奋且酷爱学习 在看他的自传里，很多时候描述就是：他每天都在思考和阅读，经常几个小时就可以读完一本书，然后挑里面的关键内容再花一天时间精读； 2. 他创业的方向一直是他从小热爱的东西 这很重要但是容易被大家忽视。兴趣是最好的老师，而做感兴趣的事情才是可以坚持一生的事情。不管是火箭，外太空旅行还是可再生能源，这些都是 Elon Musk 在孩提时期就很着迷的事情，另外更加重要的是，它们对整个人类发展有重大的意义。可能我们没有这么好的机遇或者本钱去做改变人类命运的事情，但是我们应该学会去追求自己儿时一直喜欢的兴趣，并想方设法将兴趣和自己的工作相结合，亦或是出来做自己喜欢的创业项目。 3. 他的学习方法和思维模式 在TED的采访中，他坦言自己最赞同的思维模式是 “First principle thinking”。 “First principle thinking” 的详细解释和如何运用我会在另外的问题专门回答。简单说来，First principle thinking 就是从事物最基本的公理为出发点来进行推导的思维方式。其对立的方法是 Analogy（类推法），简单说来就是别人或者其他事物如何如何，所以我也要如何如何。 举例说明：“现在我有1万刀的现金想投资股票，我应该买什么股票？” Analogy ：“别人家之前买了这几支股票，赚了不少，或者我旁边有个股票大神也买了这几个股票，赚了，所以我也准备买这几个股票。” First principle thinking：“首先去弄明白股票的原理，看清股票涨跌的本质，然后分析公司的背后价值，接着根据自己的需求，看自己是想长久投价值，然后在A股市场利用趋势捞一波。当然也有可能，在分析过程中发现股票市场的风险大小超过了自己的承受范围，从而放弃投资股票。转而杀入债市或者定期投资等。” 从上面可以看出几点：First principle thinking 对一个人的学习能力要求很高，同时分析问题的过程冗长；类推法则很方便，直接O(1)出解，只是并不知其所以然，并且缺乏对本质问题的理解。这两种思维模式的选取是一个辩证的问题：在大部分的问题上可以采用 Analogy，节约时间。但是对于重要的可能决定自己命运轨迹的问题，则采用 first principle thinking（比如创业方向？模式？，长期投资等）。 伊隆·马斯克被美国时代周刊赞誉为“当今最伟大的创新者”。太空火箭，电动车与太阳能发电，任何一个领域，都是国家级的事业，伊隆·马斯克却能独立挑战这一切。 在这里和小伙伴们一起分享一下有关Elon的牛人牛语。 创新和创业： “硅谷这里，是达尔文主义。不创新，就是死亡。“ 瞄准月亮，如果你失败，至少可以落到云彩上面。 我认为人们可以选择不平凡。 做不可能的事，本身就是有趣的。 我要么旁观，要么参与。
2015/12/17
articleCard.readMore不靠谱的敏捷之旅2015年北京站完美谢幕
这篇总结是敏捷之旅北京的组织者廉雨写的，转发于此，谢谢廉雨！ 敏捷之旅（https://agiletour.cn）是一个全球性的非赢利组织，目的在于提供一个高效有趣的敏捷开发学习途径，在全球范围内推广敏捷的思想。敏捷之旅北京站作为国内主要的举办城市，今年仍然要继续举办。下面就简单回顾一下今年敏捷之旅活动。 众筹过程 一次偶然的机会 @王立杰 在群里分享了“黑马运动会的众筹思维与粉丝经济”的文章，小伙伴们觉得可以尝试用这种方式举办今年的敏捷之旅北京站活动，于是10月10日当天开始组建敏捷之旅北京众筹微信群，不到一天的时间，聚齐了400多人。随后我们发起了众筹讲师，众筹场地，众筹大会主题等活动，最终众筹活动通过众筹网上线。 大会主题是“敏于思、捷于行，众享之旅”，是来自胡莱科技的曾著提出的，也是从30多个提出主题中，由参会者选出的。 大会的场地，由参会者主动联系各自公司，友情支持。最终参会者选择了广联达的会议室。 11月2号晚上在众筹网发起了“史上最不靠谱的敏捷聚会”项目，目标筹资¥30,000RMB，在小伙伴们和参会者一起在朋友圈转发活动，宣传这次敏捷之旅北京站活动的新玩法，截至到11月24号早上到达了目标，筹资到了¥30,757RMB，用20多天完成了这次的众筹项目，要感谢所有参与者对这次活动的支持。 活动讲师 10月15号发起了“敏捷之旅北京众筹”讲师征集，先后有20多位讲师报名参与，经过小伙伴的筛选与讲师的线下、线上的试讲，最终有13位讲师入选，还邀请了东北亚研发中心精益敏捷转型项目总监Evelyn Tian作为特邀讲师。 金牌赞助 我们联系了去年的金牌赞助商 Unlimax（安迈无限），JIRA软件中国代理，他们表示今年仍然会赞助今年的敏捷之旅北京站活动。还联系到一家做数字营销以及客户关系管理的服务商BoldSeas（彪洋科技），作为活动第二个金牌赞助商。 图书赞助 每次活动我们都会为参会者准备很多图书，这次我们联系了好几家出版社，包括：图灵出版社、清华大学出版社、人民邮电出版社、博文视点，还有个人要主动为我们的活动提供图书，特别感谢为本次活动提供赞助图书的出版社及个人。 礼品赞助 除了图书，我们还为参会者提高很多礼品，这里也要感谢提供礼品的赞助商。 1、ShineScrum提供了CSM的认证课名额一个； 2、互动出版网提供的水杯、图书以及代金券等； 3、七牛云存储提高的充电宝和小玩偶； 4、亿家净水提供的净水器3个； 5、麦思博(msup)提供的笔记本和笔； 场地赞助 最后特别感谢为本次活动提供场地赞助的广联达公司，主会场可以容纳200多人，以及不同的分会场，场地非常的赞，午餐也有多种选择，很丰盛。 组织者/志愿者 8月29号组织者们齐聚北辰世纪中心，开展了北京敏捷社区未来规划研讨会，用一整天的时间产出了北京敏捷社区的核心、目标、使命、愿景以及行动计划，这里要特别感谢@Willa（王薇）老师的引导和付出。 11月29日活动当天约300多人参会，整个大厅都坐满了，后面来的只能站在后排。还为参会者准备了各种礼品、茶歇零食以及大量的图书，最后还有CSM认证课大奖一名。 为支持千元的参会者赠送了“荣誉资深敏捷驴友”水晶奖杯和北京敏捷社区2016全年活动通行证一本。 为支持五百元的参会者赠送了北京敏捷社区2016全年活动通行证一本。 还请到了国内做视觉引导的VTC团队，他们用绘画的艺术纪录下了整个大会的过程。 最后感谢所有的参会者、VTC团队、讲师和组织者，特别感谢所有的赞助商。 资料共享 百度云盘资料共享包括：大会PPT、照片和视频等。 链接: https://pan.baidu.com/s/1qWRG2vU 密码: f64j
2015/12/16
articleCard.readMore头脑风暴七原则
本文我们一起来看看头脑风暴需要怎么做。头脑风暴多数团队都用过，不过有成果显著的，也有表现平平的。那么优秀的头脑风暴和一般的头脑风暴之间有什么区别呢？我们一起来看一下IDEO公司提倡的头脑风暴原则。 首先， IDEO非常推崇诺贝尔获奖者“Linus Pauling”的一句话： The Best way to get a good idea is to get a lot of ideas. 要得到好的点子，首先要获得很多点子。 头脑风暴有七条原则： 1. 暂缓评论（Defer Judgment） 先不要急于对别人的观点发表是非对错的评论，这样会打击提出点子者的积极性，且把集体思维的联想和延展打断。这也是对提出点子的人的尊重。 2. 异想天开（Encourage Wild Ideas） 华人总是怕自己说错话，在别人发言时，脑子想的是“我要怎么讲是对的”、“我要怎么讲才能表现我的水准”。这是因为我们缺乏允许异想天开存在的环境，只有让异想天开大行其道，才能鼓励每个人真正去思考设计，而不是思考自己的水准和对错。 3. 借“题”发挥（Build on Ideas of Others） 有些时候别人会提出来很疯狂的点子，你自己虽然是专家，知道行不通，但在座的很多不是专家，说不定听到这个疯狂的点子会得到启发、获得灵感，在这个疯狂点子的基础上，提出更实际的方案。所以，只有在暂缓评论的环境下，才能让更多的人借异像天开的点子发挥。因此前三个规则是鼓励出好点子的环境基石。 4. 不要离题（Stay Focused on Topic） 每一次讨论，要定一个明确的题目。不然的话异想天开的结局是不能收敛。 5. 一次一人发挥（One Conversation at a Time） 讲话的时候，一次一个人讲，不要七嘴八舌的。这样就没办法做记录。 网友张莹补充道：如果参与者每人有多条需要讲时，较好的做法是一个人一次只讲一条，以免出现话霸垄断了发言。 6. 图文并茂（Be Visual） 鼓励大家在想点子的时候，把这个点子用图案的方式画出来。你不是很会画图也没关系，这是因为，有时收集了很多很多点子张贴在墙壁上，也许有几百个，你过几天再回去看，如果只有文字的话，有的时候会想不起来这到底是什么。所以画图可以帮助记忆 7. 多多益善（Go for Quantity） 在限定时间盒之内，鼓励大家尽量讲，要讲究速度！后四条，则可确保脑力激荡的速度和品质。
2015/12/16
articleCard.readMoreJD敏捷创新社区第一期活动圆满完成
2015年11月27日，我们来自不同部门，为了共同的理想，相聚在一起。在欢乐声中圆满的完成第一期活动。 首先，王立杰老师给我们介绍了“JD敏捷创新社区”创立的初衷，以及我们的使命、愿景和核心价值。 1破冰 这是我们。认得出是谁吗？ 2创新工坊 创新工坊 开启 创新之旅实战演练 BOB带领我们进入游戏环节。设定游戏规则，下一秒钟，你永远不知道会发生什么~~~~ 设定一个圆，添加元素，编织出精彩的故事， 创新悄无声息的发生了；转换战场，根据新的要求添加相应元素；思维转换，让元素与元素，画面之间相互碰撞，让创新枝繁叶茂开出新的花朵。 第一组，精彩的神话故事诞生了~~~~~~~ 第二组，我们走的是科技、宇宙、穿越、爱情故事路线，小伙伴们有没有被颠覆到？ 第三组，卡通的故事画面，乐观、坚强、励志、富有想象力的故事情节让我们看到了武大郎的精彩人生。 游戏结束，梦醒了，我们通过一轮一轮的游戏环节，用手来思考，齐心协力完成任务悟出了创新的真谛。 3献计献策 最后，我们就社区的活动类别、活动方式等内容各抒己见，畅说欲言，为社区的发展确定了发展方向，从而使社区发挥更大的作用。 JD敏捷创新社区我们一直在路上，我们将携手共进创造更美好的未来！
2015/12/10
articleCard.readMore敏捷之旅北京站2015年 - 来自参会者罗涛
这篇心得是来自参会者罗涛对于敏捷之旅2015年北京站的反馈，感谢罗涛！ 本周末有幸参加了史上最不靠谱的敏捷之旅北京2015会议，整个过程采用众筹模式进行，从场地，主题到费用，感觉都不错。今天根据我的感受，主要谈谈对主题和讲师的一些感想。 在这次会议中，有很多主题，分为四个分会场进行，由于前期参与过很多次活动，所以，其中大部分内容是知道的，并且对某几位讲师也比较熟悉。因此，在选择上，更偏重于内容的选择，但发现在这个敏捷大会上，标题党也是存在的。 首先，我发现很多标题很吸引人，有些讲师的学历也很高，大多数博士啊，但是，真因为如此，太过于偏重先进理论的阐述，基本上是在从论文中提取观点，虽然自成体系，但对于我等偏重实践的屌丝来说，如果不是昏昏睡去，就是溜之大吉。 然后，对于那些实践派和工作坊，则是人气爆棚，大受欢迎，求签名求加微信瞒不过来，台上的讲师，各个都是身经百战，虽然在理论上可能略有不足，但实战经验丰富，台下听众，踊跃互动，结束后还会继续攀谈，加微信，忙的不亦乐乎！ 听众中，也有很多不同的声音，有为了求解心中问题的答案而来，又为了坚持自己的信念而来，有寻找同好而来。因目的不同，所表述各异，即使同一话题，因为听众的具体情况不同，也会出现全然不同的两种结论，现场就会进行讨论，氛围很好。 那么我的感觉是什么呢？ 首先，现在这个社会，不要再堆砌理论了，大家都是聪明人，没点干货，就不要出来浪费时间了，不关你是最新的理论成果还是酷炫的未来趋势，如果不能满足用户的当前需求，那一切都是浮云。 第二，不要纠结于理论上的完美，大部分软件工程的理论和标准都是在实践的基础上总结出来的，所以你看到的标准和理论，都是别人已经做过很多的实践，能用就用，没有匹配的，自己先干起来吧，这个互联网+的时代，产品好用是硬道理。 -———-以下为广告————— 感谢我们的金牌赞助商 ”)”) 其他赞助商 场地赞助商 礼品赞助商 图书赞助商 清华大学出版社 图灵教育出版社 博文视点出版社 人民邮电出版社
2015/12/4
articleCard.readMore敏捷之旅北京站2015年心得--来自参会者龚正
这篇心得是来自参会者龚正对于敏捷之旅2015年北京站的思考，感谢龚正！ BOB老师，您好 上周日参加的北京敏捷之旅，对于最后座谈会上大家讨论的一个问题很有感触，写了一篇心得~ -——————————————————————————– 上周日参加了北京的敏捷之旅，连续听了四位老师的讲座，新学到了不少知识，对之前的一些问题又有了新的认识。最后的一场座谈会中，大家讨论的一个问题让我联想到了两种管理思维的不同之处。 座谈会上，有位PMO的同学问到PMO员工未来的发展规划和职业道路，一位老师回答说，在自组织团队里，PMO是会消失掉的，PMO的作用是帮助项目经理管理项目，如果项目经理可以管理好项目的话，PMO就不需要存在 了，所以PMO的工作是把自己干掉，这听起来很矛盾。当时有另一个同学就反驳、并列举了他们公司中PMO的职责，比如客户的沟通、纠正项目经理管理中的问题、提供项目经理职业发展规划、督促项目经理进行自我提升等等。最后因为会议时长的原因，这个话题就没有继续讨论下去。 话题结束后，我开始思考传统的管理思路和敏捷管理思路的区别。传统的管理方法中，管理者好像在假定下级的管理者和员工因为经验的缺失、视野不够高，他们的管理能力是不胜任的，所以才需要进行监督和控制，管理者把大量的精力投入到对项目的管控中，当项目越来越多时，管理者便设立了PMO辅助他进行项目管理，PMO办公室开始制定项目流程、控制项目过程、用KPI考核绩效，用项目管理的工具来跟踪项目的执行。 敏捷的管理思路更多的是强调团队的自组织和自律性，认为团队可以自行的做好自己的计划、执行和监督的工作。所以不需要管理者过多的干预，团队也可以自发的协调好彼此的关系，管理者需要信任下属，给予他们适度的授权。 两者的区别类似于管理学中的X理论和Y理论，传统管理思维认为大部分人是被动的，所以需要被管理，而敏捷管理思维则认为大部分人是主动的，所以他们可以自己管理自己。两种不同的出发点，产生了两种不同的管理方式，采用哪一种管理方式，则取决于管理者的性格和所处的环境了。 -—————————————————————————- 谢谢BOB老师还有其他的会议组织者，周日一天学了很多东西~ -—–以下是广告—— 感谢我们的金牌赞助商 ”)”) 其他赞助商 场地赞助商 礼品赞助商 图书赞助商 清华大学出版社 图灵教育出版社 博文视点出版社 人民邮电出版社
2015/12/3
articleCard.readMore《父母效能训练手册》读后感
这本书很早之前就买过一本，大致看过目录，感觉是一本不错的书。不过一直没有详细阅读。 最近想翻出来看的时候发现不知书去哪儿了，只能破费再买一本。 本书中我最大的收获是，要区分是谁的问题。父母和孩子发生冲突后，是孩子的问题，还是父母的问题？ 很多父母，包括我自己也是这样。经常会分不清楚到底是谁的问题？ 如何区分呢？ 问题属于孩子时 我的体会是，先问自己，孩子的这个行为给我带来什么影响？如果木有影响或者只是面子问题，那么多数这个问题是孩子的问题。比如说： 孩子早上赖床 孩子不好好吃饭 如果是孩子的问题，并且孩子需要帮助，那么从长远来看，最有效的帮助方式就是不提供帮助。 这里的不提供帮助，不代表要忽视孩子存在的问题，转而去做父母自己的事情。而是不提供父母的解决方案。 比如父母可以用如下方式进行沟通： 简单的敲门砖 积极倾听 问题属于父母时 当问题属于父母的时候，父母可以有如下做法： 直接改变孩子 改变环境 改变自己 书中有一个例子，很生动的描述了这3个做法。有兴趣的可以买书，翻到105页仔细阅读哦。 本书给我另外2个启发是： 我-信息 如何实践“没有输家”的解决方案 我-信息指的是在沟通的时候，要更多采用我开头
2015/11/19
articleCard.readMore翻转组织—通用医疗敏捷转型案例
标题：翻转组织—通用医疗敏捷转型案例 副标题：在强监管下启动敏捷项目，组建自管理团队 首先说明一下这个案例是我的好朋友黄喆和他的同事方建国亲身经历，在DanielTeng的辅导下所实现的敏捷转型。 本文一共分为3个部分，这是第一部分。 在规模化敏捷中组织文化转型和组织结构转型一直是两个很棘手的问题。如何构建跨职能、跨模块的全功能团队？如何导入自组织的文化？团队自设计的过程可能是同时解开这两个难题的钥匙。本文将展示一个在大型医疗企业中进行团队自设计的案例，希望可以为读者带来一些启示。 背景&结果 在选敏捷教练进入之前，GE Surgery SW团队已经自己在敏捷的道路上进行了1年左右的探索。当时团队的状态是： 1团队文化有“自组织”的萌芽，但命令和控制仍是主流。 2有Sugary的产品包括三大子系统：Xray Control, Imaging以及Application。共五支跨职能团队（包括开发和测试人员），每支团队分别负责不同的子系统，具体如图1所示。这就导致team在开发一个用户关心的feature时，需要很多倒手和协调的工作。一个功能要倒手几次才能进行系统集成，降低了交付效率。同时，这也迫使PB中存在很多的TechnicalStoy。项目PO在计划PB时不能完全按照客户（医生）的需求去排列feature开发的优先级。 3五支团队有一名项目PO，维护整个产品的PB。每支团队各有一名team PO，维护team一级的PB。每个团队的PO关注的是较细节的需求，但这实际上应该是团队关心的内容。每支团队独立的PB也比较容易引发局部目标和整体目标的冲突。 4每支团队都有一名兼职的SM。由于同时兼职开发工作，所以这位SM的工作基本以引导各种Scrum会议为主。没有更多的精力去帮助团队改进和成长。 在敏捷教练团队（Daniel Teng和他的同事们）进入GE Surgery SW团队并进行了评估后，他们提出了两种启动敏捷转型的方法：一种是变革式的，而另一种是渐进式的。他们和Surgery SW经理高剑宏进行了一次深入的探讨，并决定对组织文化和组织结构进行一次由内向外的变革。随后Daniel设计并引导团队进行了团队自设计的工作坊。这次里程碑式的工作坊在Surgery SW内部也被称为“团队成年礼”。通过这次成年礼，团队完成如下转变： 1组织开始转型为“自组织”型的组织文化。团队的自组织意识得到了很大的鼓励和提升。 2组建了4支具备端到端开发能力的跨模块的Feature Team。打消了团队之间的依赖。 3取消了团队一级的PO和PB，只保留一个项目一级的PO，维护一份整体项目的PB。4支团队都只关心整体目标，避免了局部目标和整体目标冲突的问题。 4设置两名专职的SM，每位SM负责两支团队。SM可以更深入的引导团队进行持续改进。 接下来让我们来看看团队评估和成年礼的具体过程。 评估和筹备 在Coach进入团队进行了为期3天的评估后，Daniel向Surgery软件经理高剑宏提出需要对团队进行一场由内到外的变革。这意味着两个方面。首先，要将团队的组织文化转变为“自组织”型的文化，让团队成员成为“成年人”。其次，需要对团队的组织结构进行调整。建立功能团队，合并PO和PB，设置专职的SM。 这对于SurgerySW无疑是一场深入而巨大的变革。作为经理的高剑宏需要考虑变革所带来的好处及其可能引发的后果。团队是否可以适应新的组织文化？团队结构的调整势必会造成一部分已有工作的浪费并对项目造成一定的影响，这样的影响是否可以接受？在这种转型中，经理的角色应该发生怎样的转变？种种问题并非短时间 可以考虑清楚。所以在提出建议后，Daniel请剑宏仔细的考虑三天的时间。最终，三天后剑宏给出的答复是“Goahead!”。一场由内而外的变 革也随之拉开了帷幕。 转型前的Surgery SW团队的管理水平大致位于“Manager-led team”与“Self-Managing team”之间（见图4）。团队可以管理Sprint内部的工作，但团队的工作流程、DOD以及每个Sprint所做的Feature都是被管理层（经理、PO以及SM）所指派的。而这次转型的目标是要让团队达到“Self-Designing team”的水平。这就需要将认领任务、制定工作流程、定义DOD以及团队设计的权利移交给团队。受到Craig Larman和Ahmad Fahmy的“How to Form Teams in Large-Scale Scrum? A Storyof Self-Designing Teams”的文章的启发，Daniel建议引导团队进行一次自设计的工作坊。在这次工作坊上Coach会引导团队进行自设计，选举他们认可的SM，并定义团队自己的流程和DOD，以此完成权利的移交，从而带动组织文化朝“自组织”方向转型。这项建议随后也得到了高的同意。 作为前期准备的一项重要活动，在自设计工作坊前一周，教练还通过微信群将相关的消息提前发布给了团队。并告知如果希望竞选SM的同学需要提前准备一个2-3分钟的竞选演讲。这一提前准备活动为团队提供了一个“转型”的信号，同时也让团队中的成员有较充分的时间思考是否愿意竞选SM。 本文一共分为3个部分，这是第二部分。 团队自设计工作坊——成年礼 当天 所有的团队成员和Coach都参与了这个工作坊，Daniel先引导团队进行了一个破冰仪式。之后，经理高剑宏介绍了本次团队重新组建的目的： 1消除团队间的依赖，提升团队的端到端交付能力。 2最终形成4支全功能团队，每支团队6名成员。 3选举两名专职的ScrumMaster。 整个自设计工作坊为期一整天，其具体计划如下： Scrum角色介绍（2小时） SM发表竞选演说（0.5小时） 团队自组建（1小时，2个迭代） 团队选出他们希望的SM（10分钟） 团队确认自己的现状和发展目标（1小时） 组建虚拟团队（2小时） Scrum热身介绍 为了让团队可以就PO和SM的具体职责达成一致。Daniel首先为整个团队介绍了Scrum中的角色和职责，让大家对理想的团队和SM建立了基本的概念。
2015/11/15
articleCard.readMore敏捷需求之分层管理
传统软件开发（或者说瀑布式软件开发）方法，对于需求的看法是 – 尽可能详细的了解需求、分析需求以形成详尽的需求文档，然后就把文档交付给开发部门。敏捷软件开发中则是完全不一样的做法。首先敏捷需求是ODDE的，其中有一个点很重要就是Detailed Rightly (Appropriated) – 详略得当。 什么是详略得当 介绍详略得当之前，我们先看一张图 在上图的产品列表（Product Backlog）中，最左边分为几个部分：已完成，细粒度，粗粒度，下一版本。已完成无需介绍，下面分别介绍一下细粒度，粗粒度，下一版本。 细粒度 细粒度的意思是这些产品列表条目是相对比较明确的，详细的。团队对于这些条目的认知是达成一致的。经常有学员问我，那这些条目到底多大合适？这里有一个经验值供参考（根据行业不同会有很大不同） – 一般来说，一个团队在一个迭代内完成6-12个条目为宜。细粒度一般也意味着马上要做的条目。 粗粒度 粗粒度指的是这些条目的细节还不清楚，团队有可能没有达成共识。粗粒度一般是接下来2-3个迭代要做的条目，并且会在产品列表梳理会上，对粗粒度的条目进行拆分、澄清，从而有可能变成细粒度的条目。 下一版本 有一些条目是近期不会考虑的，但从产品规划上需要有考虑的。比如正在做一个安卓APP，从长远来看是需要做iOS版本的，不过可能要3个月后才会考虑。这样的条目就是下一版本的。 为什么详略得当很重要 敏捷需求是有分层的，正如上一节讨论的，分为：已完成，细粒度，粗粒度，下一版本。 如本文的题图（感谢Alistair Cockburn博士），产品列表中的条目也是可以分为鱼虾级别（故事）、大海级别（Epic）和风筝级别（Theme）。 那么为什么详略得当如此重要呢？ 这是因为产品列表条目，我们（作为人类）不可能一次获得所有信息。在产品开发的早期，获得的信息尤其少，那这个时候做出的需求分析（或决策）怎么可能包含所有的条目呢？因此条目就不可避免的有大海和风筝，只有少量的鱼虾可以完成。随着完成的鱼虾越来越多，我们获得的信息也越来越多，对产品的认知也越来越清楚，从而能够做出更加可信的决策。 写在最后 本篇文章起源于“敏捷之旅北京众筹群”中，和火星人陈勇之间的一次讨论。我的观点和陈勇老师略有不同。用户故事，顾名思义，是从用户的角度来讲故事。那么它的核心是产品负责人和开发团队之间都了解这个用户故事是解决什么问题的。而不是一定要从Theme拆分成多少个Epic，从而再拆分成多少个Story这样的一个过程。 讨论原文如下： 火星人 18:20 我在开发中摸索出一个新体系，能在战术层面融合uml fpa story scrum mvc这几个东西 火星人 18:21 以前都是战略层面上融合，“兼容”但是没有具体做饭法 火星人 18:26 最近做项目的时候发现了一种很多人本能会用但稍加改良就能统一所有方法的东西 火星人 18:43 涉及到jira中theme epic story三层需求的定义 火星人 18:44 用这种方法可以让两个人分解出来的三层内容几乎相同 火星人 18:46 就是因为头疼分解问题，我观察了项目前期的需求，发现了一些规律。等我到笔记本上打字吧 火星人 18:50 我们发现有一种故事比较“舒服”，就是可以放在“作为一个……，可以（故事）……，以便……”，这种故事都是动宾词组，比如“上传简历”，“查看商品”等等，从文学的角度正好放在“可以”后面。 火星人 18:50 另外一种故事则有点问题，比如“货物管理”“配置子系统”，完全不可能“可以货物管理”，或者“可以配置子系统” JinKenny 18:51 这就是As a…I want….So that…结构 火星人 18:51 后来我们就把洞宾词组的放在第三层（Jira和TFS都叫Story），名词的放在第二层，并将其分解为相应的动宾词组 火星人 18:52
2015/11/13
articleCard.readMore引导技术大揭秘
引导是什么 从英文来看facilitate的意思是使能够、使之变得更容易的意思，大致可以延伸理解为支持并推进。 国内对facilitate的翻译包括引导、催化、促动、建导等。 入门大揭秘 入门法则快速记忆–TRRE 时间盒（Timebox） 引导之前，首先要明确时间规则。有两点需要注意： 明确作为引导师，你有多长时间。比如10分钟、1小时、1天，时间不同选择的引导技术和工具是截然不同的。 在引导过程中，需要给出明确指令，接下来的环节是多长时间。比如5分钟、7分钟等。同时会用计时工具进行计时。 结果（Result） 接下来要介绍的是这个环节的产出是什么，或者说对参与者的期待是什么。结果或产出一定要具体，也可以结合下面的例子环节，给出具体示例。 规则（Rule） 然后就需要介绍规则是什么。介绍规则的时候，还可以介绍一下哪些是违反规则的，给出示例。 上述TRR讲完之后，可以结合在一起给出完整的例子。 示例（Example） 如果是非常简单的引导技术和结果，可能会略过例子环节。而我碰到的大多数引导过程是需要给出例子，或许是引导师邀请参与者共同示范。 总结 引导技术入门是TRRE，即Timebox,Result,Rule,Example–时间盒，结果，规则，示例。
2015/11/5
articleCard.readMore史上最不靠谱的敏捷聚会
现在钱不值钱的时代，100元竟然还能这么超值，这帮家伙一定脑子浸水了，一帮有爱的家伙 做个爱学习的IT人，不只是开发人员，研发团队所有成员都应该开放的来学习。名额有限，100元可获得敏捷之旅2015北京站纪念奖章一枚，大会PPT，门票1张，价值30元精美笔记本+笔一套，价值50元的敏捷图书一本，价值6000元CSM免费培训的抽奖机会，还有更多赞助商礼品等着你…… 支持我们的众筹 我们为什么要众筹 本次会议（敏捷之旅北京2015）是参与者的会议，你想有一个什么样子的会议都可以参与讨论、设计、提议（筹钱、筹力、筹讲师、筹场地、筹平台等）。每位参会者都能够真正参与其中，发动自身的资源，邀请好友，推荐讲师，联系场地，寻找赞助都可以。任何想法都可以@廉雨 或者 @姜信宝 众筹的收益： 1. 交到志同道合的朋友 2. 支持敏捷社区发展 3. 与业界敏捷精英交流与分享彼此的敏捷实践与心得 4. 抽奖获得各种奖品和书籍
2015/11/4
articleCard.readMore什么是敏捷教练
最近和几个新朋友聊天，自我介绍的时候说我是敏捷教练。紧接着问题来了，朋友经常会问什么是敏捷教练？ 下面是我微信朋友圈几个不错的解释： 授人以渔 敏捷+教练 敏捷价值观的布道者 有能力协助排除敏捷障碍的人 引导者 高情商的牧羊犬 下面是我的理解（观点）： 敏捷教练，对应的英文是Agile Coach，也就是说它是两个词的组合，即敏捷+教练。下面我们分别了解一下什么是敏捷，什么是教练。这对了解敏捷教练非常有帮助。 什么是敏捷 敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。（摘自wikipedia） 敏捷的另一个定义 – 敏捷是尽早频繁地交付商业价值。（感谢Alistair Cockburn） 什么是教练 国际教练联盟（International Coach Federation) 定义教练：“ 专业教练作为一个长期伙伴，旨在帮助客户成为生活和事业上的赢家。教练帮助他们提升个人表现，提高生活质量。教练经过专业的训练，来聆听，观察，并按客户个人需求而定制Coaching方式。他们激发客户自身寻求解决办法和对策的能力，因为他们相信客户是生来就富于创意与智慧的。教练的职责是提供支持，以增强客户已有的技能，资源和创造力。”（摘自百度百科） -—————–华丽丽的分割线—————— 我们了解了什么是敏捷，什么是教练之后，现在来看看敏捷教练到底干什么？ 敏捷教练做什么？ 敏捷教练做的工作主要分为3个方面： 个人方面 敏捷教练要有能够搞定关键人物（如Sponsor，经理，团队里的tech lead等）的能力。这个能力包含但不限于教练，个人影响力，唤醒者工具箱等。 团队方面 敏捷教练能促使团队自组织，成为高效能团队，并能够自驱动变得更加高效。 组织方面 仅仅一个团队变得高效并不能保证整个组织高效，或者产品的高效产出。这还需要整个组织变的高效。这可能包含但不限于组织结构的调整、工作流程的调整、工作环境的调整等。 -—————–华丽丽的分割线—————— 熟悉Scrum的朋友应该知道有一个角色叫ScrumMaster，那么ScrumMaster和敏捷教练又有什么区别呢？（摘自David Ko的博客） Scrum Master 對象: 針對某個團隊 任務: 主要是重心是幫助團隊實施 Scrum 和專案的關聯: 通常和專案緊密結合 和團隊的關聯: 是團隊的一份子, 要保護團隊 所需要的訓練: Scrum master 這個角色要懂的事情 有敏捷的相關經驗: 不必要 敏捷教練 對象: 針對個人或是團隊 任務: 變革管理, 敏捷性 (agility) 和專案的關聯: 和專案無關, 或是說並不隸屬於某個專案
2015/10/23
articleCard.readMore史上最不靠谱的一次敏捷聚会！
唠叨几句 为什么不靠谱？因为每年敏捷之旅都是要先招募组织者，然后由组织者来决定会议时间、地点、流程、讲师等等。今年我们想来点不靠谱的事情，所有的内容全部由参会者来决定，每个人都可以发动自身的资源，邀请好友，推荐讲师，联系场地，寻找赞助。 10月10日有了这个想法之后，一个下午的时间约400人就聚集在一起。 敏捷之旅众筹介绍： 什么是敏捷之旅 敏捷之旅（Agile Tour）是每年一度的非营利性系列会议，旨在把敏捷社区联系起来，系列会议分别在全球众多城市召开，从10月份开始到12月份结束前后历时数月。如今已步入第8个年头，敏捷之旅目前正走向全球，并且获得了敏捷联盟（Agile Alliance）及Scrum联盟（Scrum Alliance）的支持。 敏捷之旅中国从成都站开始，到今年已经有20个城市举办过敏捷之旅，每年参会人数达到2000多人。 为什么要众筹 本次会议（敏捷之旅北京2015）是参与者的会议。给自己办一次聚会，会议内容、流程方案、讲师筛选、场地布景，这些都由你决定。每位参会者都能够真正参与其中，发动自身的资源，邀请好友，推荐讲师，联系场地，寻找赞助都可以。任何想法都可以@廉雨 或者 @姜信宝 众筹的收益： 交到志同道合的朋友 参加会议 抽奖获得各种奖品和书籍 众筹参与规则 众筹参与规则（草拟，大伙可以跟，并修正）: 1.我组织，转发@廉雨 的众筹宣传图片到朋友圈 或者拉5个感兴趣的人入群。 2.我出力，认领一件任务，免活动门票。（联系@廉雨） 3.我出钱，众筹本次会议费用（具体再定） 4.第一条必选，第二条第三条必选一条 当前进度 A. 愿望列表 敏捷之旅北京众筹愿望列表，格式“1. xx愿望+你的名字”，请大家复制本条消息接龙，要求简洁明了: 1. 希望有户外活动，不仅仅户内分享—王立杰 ； 2. 希望有大牛分享，如Henrik Kniberg—姜信宝； 3. 实战的案例分享和演练—尹利霞； 4. 希望有失败案例和问题分析—王璐； 5. 希望分享大企业如何做敏捷转型案例或思路（如果没有案例）； 6. 如何将传统团队及流程顺利移植到敏捷—春儿； 7. 能众筹一个自己的xx馆做活功基地—张学海； 8. 敏捷团队组织与建设+案例分享—王彬； 9. 众筹一个敏捷书店—李建昊； 10. 希望可以把敏捷的理念推广到传统行业，如制造业等—王梓晨； 11. 继续去年讨论过的敏捷育儿话题— 何永振； 12. 与国际敏捷组织交流—刘静； 13. 希望定期（每月）有活动—刘广民； 14. 建立积累维护一个敏捷实践的案例库 （成功、失败，各种场景….) —贾锦杰。 15. 各种常用敏捷开发或测试使用的工具介绍—曾莉莉；
2015/10/17
articleCard.readMore如何筹备一次如QCon一样的千人大会（活动）
以前没有筹备过大型会议（如QCon，MSUP等）之前，我也会觉得好厉害啊，可以组织这么大规模的会议活动。在有过几次组织会议经验之后，我也想跟大家分享一下我的一些经验，都是一家之谈，如果有不对的地方也请观众不吝赐教。 版本信息 v0.1 2015.9.28 第一版 前言 为什么会有这么一篇文章呢？ 有一个朋友上周问我，有关组织敏捷之旅有没有什么参考资料？我记得之前有一篇文章的，可惜网站（https://agiletour.cn之前的网站）几经转折之后，那篇文章找不到了。既然已经答应朋友帮忙找一些参考资料，本文就当做是一个组织敏捷之旅活动的起点吧。（也完全适用于其他组织会议或者活动） 本文的结构分为活动前、活动中、活动后。 活动前 活动前的准备，可以说是重中之重的环节。如果准备环节搞砸了，或者准备的不充分，那么现场（活动中）就很难办了。活动前的准备工作分为以下几类： 时间 地点 财务 人 流程 宣传 后勤 时间 选择时间： 选择时间的时候，需要考虑几个因素：避开小长假；避开其他同类型活动；尽量选择周末；选择时间的时候最好有2个可选项，因为有的时候场地不一定可以。 启动时间： 举办一次活动，首先要确定好什么时间办，然后从举办时间开始向前倒推。一般性的会议（比如参会人200左右）大概需要1-2个月的准备时间。比如有个活动想要12月5日举办，那么准备活动在10月5日就应该启动，最迟不应晚于11月5日，否则只能向后顺延活动日期。 地点 敏捷之旅的活动地点，一般都是尽量找免费场地，或者是赞助的场地，以减轻财务压力。北京的活动场地，尽量选择北边，比如中关村或者上地区域。地点要配合时间一起确定，时间地点确定好了以后，就可以考虑启动各项准备工作了。 财务 在活动启动的时候需要制定一个预算表，并时刻关注财务预算。针对敏捷之旅，收入主要是两块：赞助费和门票收入。支出大概为：场地费（如果没有免费场地或赞助场地）、参会人的午餐（一天活动的话，建议订餐一起吃，这样可以增进交流）、讲师差旅费、讲师礼品、抽奖奖品。 门票收入牵涉到如何收费的细节，需要着重考虑。 赞助 针对赞助多说一点。敏捷之旅的赞助分为几个类型： 现金赞助（可以分为白金赞助商、金牌赞助商、银牌赞助商） 场地赞助（赞助活动的场地） 图书赞助 媒体赞助 人 人物角色主要有五类，分别是：组织者、志愿者、主持人、讲师、参会人。 组织者 组织者团队规模建议控制在9人以内，最好能大于3人。“搭班子、定战略、带队伍”–柳传志总结的管理三要素，同样也适应于组织活动。活动的第一步就是要搭班子，确定组织者队伍。 志愿者 志愿者是活动当天需要的帮手，可以考虑社区内的活跃分子，实在找不到也可以从高校招募。一般如果200人的活动，志愿者大概需要5人就可以。签到台3名，会场门口1名，场内1名。 主持人 主持人的职责：负责介绍讲师，进行活动的串场。一般分会场的主持人也是该分会场的负责人。上午大会场的主持人还需要几点注意事项：比如介绍赞助商，介绍整体日程，介绍敏捷之旅等（具体事项在会议前还需要协定） 讲师 讲师的招募分为两个途径：1. 公开招募 2. 邀请制。 可以根据实际情况，比如设置一个deadline，在这之前如果招募的效果不理想，即刻启动邀请制。 参会人 这个和下面的宣传紧密联系在一起。 流程 这里的流程指的是活动的整体安排，即活动日程。日程安排是需要整体考虑的。比如是否需要有分会场，是否需要开放空间，闪电演讲，是否有抽奖环节，如何操作等。 另外活动日程和讲师的招募也是息息相关的。所以找讲师的工作需要尽早开展。 宣传 宣传工作分为宣传内容和宣传渠道。 宣传内容 宣传内容为根本，是宣传渠道的输入。不过宣传内容主要来自于讲师和话题，所以讲师的招募（找讲师）还是要放在前面。有了讲师和话题，就可以制作宣传内容，也就可以安排开始宣传了。 宣传渠道 常用的宣传渠道为：微信、微博、邮件、网站。有了宣传内容之后，就可以在不同的宣传渠道进行宣传。另外可以和一些媒体进行合作，比如InfoQ，MSUP，CSDN，51CTO等。 后勤 后勤的工作都是一些非常琐碎细节的事情，一般也不需要启动的太早，在活动开始前一周细细的梳理一遍基本上都来得及。 后勤工作包括：用餐准备、活动路线图、讲师差旅、报名平台、参会者付款、讲师礼物和抽奖奖品。 活动中 活动中指的是活动前一天，活动当天所发生的所有事情。 活动前一天 短信通知参会人具体的活动时间、地点 组织者+志愿者布置场地（以及签到台），以及调试设备（投影和麦克风） 活动流程的彩排（模拟签到等） 活动当天 活动当天的事情包括：
2015/10/8
articleCard.readMoreScrum书籍推荐
为什么是Scrum书籍推荐 说一下为什么这里推荐Scrum书籍推荐而不推荐敏捷书籍。因为采用敏捷方法当中，有95%的人实际采用的是Scrum框架。这也就是说，很多人都在说敏捷，其实就是特指Scrum框架。（信息来源是2015年ScrumAlliance发布的Scrum状态报告）见下图： Scrum书籍必读 入门必读 首当其冲推荐给大家的是《Scrum指南》（共14页，中文）。《Scrum指南》是Scrum的发起人Jeff Sutherland和Ken Schawaber共同撰写的，最后更新于2013年7月。下载链接如下（免费） https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-CN.pdf#zoom=100 实践必读 实践必读推荐两本很经典的读物：《Scrum简章》（免费）和《硝烟中的Scrum和XP》（免费） 下载链接： 《Scrum简章》 - https://scrumprimer.org/zh-cn/ 《硝烟中的Scrum和XP》 - https://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches 英文第二版链接 - https://www.infoq.com/minibooks/scrum-xp-from-the-trenches-2 高级必读 如果了解完Scrum的理论和实践后，还想更深入的了解Scrum。那么这本书你绝对不要错过 - 《Scrum精髓》。书如其名，本书介绍了Scrum中的核心内容。 如果想用Scrum来开发足以引爆流行的产品和服务，本书就是你梦寐以求的完全参考。作为业内领先的敏捷教练和培训师，Kenneth Rubin用通俗易懂的语言和丰富的实例与我们分享他十多年的实践经验，诠释Scrum的价值观、原则和实践，描述一些灵活、可行的方法帮助我们用好Scrum。 针对Scrum新手和达人，本书从团队、产品和产品组合这三个层面来介绍、澄清和深化Scrum的相关原则和应用。Rubin曾帮助数百个组织成功应用Scrum，积累了相当丰富的实践经验和表达能力。作为这些经验和能力的结晶，本书图文并茂，通过通俗易懂的描述和两百多幅图对Scrum进行了阐述，这些图采用的是一种全新的视觉图标语言，用于描述Scrum的角色、工件和活动。 《Scrum精髓：敏捷转型指南》可以帮助团队成员、经理和执行主管了解Scrum常识，掌握可以拿来即用的通用词汇表，充分攫取Scrum的潜力，最终实现优秀团队能够做到持续、稳健发展的目标。
2015/9/23
articleCard.readMore在线写书工具大比拼-gitbook selfstore 知笔墨
在线写书工具大比拼 本文主要调查了gitbook, selfstore,leanpub和知笔墨4个工具。本文仅代表作者个人体验，如有不当的地方，欢迎来信。以下是几个对比的维度： 写作工具 版本管理 费用 写作工具 gitbook 在线的编辑器，允许增加协作者共同修改图书，支持markdown语法。可以为图书新建一个html的页面进行描述。英文界面。 leanpub 在线的编辑器，支持markdown语法。可以导入word，wordpress。英文界面。 selfstore.io 是一个在线销售自己电子书的平台，支持100M以内的各种文件格式。如果需要写作还得需要其他平台。中文界面。 知笔墨 处于测试阶段。支持在线编辑，支持git版本管理。中文界面。 版本管理 gitbook 支持git版本管理，也可以连接到自己的github账号。 leanpub 支持git版本管理，支持链接github，dropbox，Bitbucket，或者word，wordpress导入。 selfstore.io 无。只在线销售图书，可以上传任何格式的文件。 知笔墨 支持git版本管理 费用 gitbook 针对paypal（贝宝）账号付款，收取2.9%+30美分。银行卡付款未提到。美元结算。 leanpub 每笔交易的10%+50美分。美元结算。 selfstore.io 每笔交易的5%+0.5元。人民币结算。 知笔墨 支持打赏和收费两种，具体收费形式未知。
2015/9/7
articleCard.readMore北京敏捷社区未来展望结果-20150829
北京敏捷社区未来规划 首先非常感谢好朋友Willa，牺牲自己的周末时间来帮助北京敏捷社区进行未来规划！同时还要感谢北京敏捷社区各位小伙伴！（会后大家说这一天比上班还要累）经过一整天（早9点到晚9点）的辛苦工作，我们最后产出了北京敏捷社区的愿景、使命、总目标、正向核心以及关键事项。 北京敏捷社区的愿景 帮助组织提升敏捷实施能力 北京敏捷社区的使命 致力于打造一个多元化交流平台，不断积累专业知识与实践经验，提高多领域敏捷实践者的专业水平，帮助个人和组织交付更多的价值。 总目标 价值目标 帮助个人和组织交付更多价值 专业度目标 持续地积累专业知识与实践，提高社区的专业水平 活跃度目标 最大程度地使各领域实践者持续地自发组织参与“北京敏捷社区”的交流互动 正向核心 专业的影响力 积极开放的心态 勇敢的坚持 关键事项
2015/9/4
articleCard.readMore京东敏捷软件开发精髓
大家好，我是今天的分享老师：姜信宝，Bob Jiang。我来自京东商城-技术研发管理部，是京东的敏捷教练。 很高兴受到“京技院“的邀请，能有机会与大家分享关于京东的敏捷软件开发商的一些心得体会，希望分享的内容能给大家带来一些收获。这次准备的时间有些仓促，同时我也是第一次通过微信的形式做这种交流，有不足的地方还希望大家能够理解。：) 今天我的分享话题会分为两大部分： 1.案例分享 2.敏捷软件开发的精髓 下面我们来看一下第一个案例，京麦团队。相信如果关注京东敏捷开发的朋友，对于这个团队并不陌生。京麦团队是京东的第一个敏捷团队。到目前为止该团队没有一个员工离职，这在互联网行业可以说是一个奇迹了。 案例1：京麦 2012年底，有一个屌丝团队，他们做的产品慢慢被边缘化，客户不满意现有产品，技术负债高，并且团队马上要被解散去做其他产品了。这个场景听起来熟悉吗？ 很幸运的是，团队leader旁听了一次敏捷的工作坊，知道敏捷应该怎么玩，也知道了和其他团队之间的差距在哪里。因此京麦团队决定试一试，用敏捷开发的方式进行软件开发，有了想法马上行动。 第一步，组织团队进行敏捷培训，全员知道什么是正确的敏捷软件开发。这是敏捷软件开发的第一步，也是至关重要的一步。 第二步，团队坐在一起，这里团队指的是产品、研发、测试整个团队，而不仅仅是研发。团队坐在一起的好处有很多，比如有了问题，直接喊“张三这个问题我们一起看一下？” 又或者产品和研发正在讨论某个具体的需求，测试人员听到后立刻加入进来，信息快速共享并达成一致。 另外，团队坐在一起还有其他的好处，团队的每日站会更加容易同时一起开，代码评审也会随时随地的发生，任务板上的任务团队更容易更新。简言之，团队坐在一起更容易促成团队之间的沟通，以及信息共享。 第三步，按照Scrum框架的定义，严格地开展每一个会议，如迭代计划会、每日站会、迭代评审会、迭代回顾会以及产品列表梳理会。每一个会议都不能省略。 第四步，Scrum会议坚持开的情况下，团队可以尝试引入已经被证明有效的良好工程实践。如持续集成、结对编程、测试驱动开发等。 在坚持以上四步之后，京麦团队达到了如下的成果： 1.交付周期从之前的12周，降到现在的2周 2.同时在线的用户数提升了3倍 3.活跃用户数提升了5倍 京麦团队到现在敏捷转型接近三年，团队也已经拆分成4个小团队，整个团队还是在坚持着使用Scrum的方式，每两周一个迭代，持续交付价值，持续改进。下面是他们团队任务板的一个持续改进图，供大家参考。 这是他们第一版的任务板 第二版 第三版 最后在京麦团队的带动下，整个POP团队都已经开始了敏捷转型之旅，非常感谢京麦团队不懈的坚持。以上是第一个案例的分享。 案例2：物流开放平台 介绍这个案例之前，我想先说一下团队的收获。这个团队在人员数量不变的前提下，2015年上半年就完成了2014年一年的任务量，即团队效率至少提升了1倍。想知道这个团队是如何做到的吗？我们一起来看看这个团队的例子。 首先这个团队经理是很开放的一个人，喜欢新鲜事物，喜欢尝试。这是非常好的开端。 第一步，仓储团队的总监找到我们，商量进行大团队的敏捷转型。这里多说一下，为什么这个团队的总监会找到我们。前期我们（敏捷教练）在POP京麦团队的成功试点，很多团队也都听说了敏捷可以成功的，因此越来越多的团队也想进行敏捷转型。也就是说通过早期成功的样板团队，树立了榜样，也为后期的敏捷转型铺好了路。 第二步，敏捷导入，即进行普及性的培训。上面提到的团队经理和他手下的几个leader都来参加了ScrumMaster敏捷训练营的培训。 （这是团队经理听完培训之后的反馈：“在京东第一次接触敏捷研发管理的思想，是在今年春节前一次公司组织的敏捷培训课程上，听了敏捷教练BOB的授课，感觉这种管理模式既可以改善现有研发工作中的一些问题，又能给团队带来很多新鲜事物，真是我们迫切需要的。于是，在部门领导的倡导下，我们几个三级部门开始了各自团队的敏捷之旅。”） 第三步，团队开始按照Scrum进行敏捷软件开发，并且持续改进。大多数团队一开始都会选择两周作为一个迭代周期，因为两周是一个很好的开始点。 制定了团队规则之后，就要执行。比如“最初开站会的时候，大家都不是很积极，到了规定的时间，很多人还在忙自己的事情，不叫不来。后来敏捷团队制订了奖惩机制，每天不按时参加站会又不提前请假的，都要扣20块钱作为水果基金。这下大家的积极性提高了，每天参加站会的人也比较齐全了。有一次一个同事因为处理问题，晚来了2分钟，本来是有情可原的，但为了兑现承诺，他主动买了5盒草莓分给大家。”。 另外，回顾会议是非常关键的。“在敏捷回顾会上，大家都要总结上个迭代周期里工作情况，包括做得好的地方和需要总结提高的地方。会议由Scrum Master主持，每个人会拿到不同颜色的便签纸，蓝色的便签纸上写做的好的实例和总结，红色的便签纸上写的是待提高的事例和建议。在写完总结后，大家会按顺序轮流发言，提出自己的意见和建议，最终汇总到Scrum Master处。每次回顾会，都会让大家获得很多的经验和宝贵的意见，从而提升整个敏捷团队的工作质量。” 在部门领导和公司管理层的支持下，我们敏捷团队鸟枪换炮，从以前传统的墙面看板，上升为触摸电视屏幕的电子看板。怀着激动和感激的心情，我们几个小伙伴瞬时间将高大上的触摸电视和支架组装完毕。 在团队敏捷转型的一开始，为了让大家对Scrum有更全面的了解，团队还自发组织了读书行动。每天固定时间固定地点，团队花30分钟共同阅读同一本书，并且大家会就这一个主题进行讨论。 可视化的读书结果 以上就是第二个案例分享，物流开放平台。 案例3 - 京东途牛融合项目 5月8日京东和途牛联合宣布，双方展开深入战略合作。6月下旬，我作为敏捷教练进驻途牛团队，帮助途牛项目一期进行敏捷软件开发的辅导。 针对全新项目的转型，有以下几点需要注意。 第一，需要先梳理出第一版的产品列表（Product Backlog）。一开始我就和途牛团队的8位产品经理进行产品需求的梳理，并且使用用户故事地图进行了产品需求的大概规划。 第二，团队坐在一起。产品研发和测试全部坐在一起。由于这个项目的特殊性，需要和途牛进行频繁的接口测试和联调，途牛团队也安排坐在一起了。 第三，形成Scrum of Scrums（SoS）会议。这个项目有四个团队，跟团游、门票、平台、途牛方。每个团队都有自己的每日站会，固定每天下班前每个团队代表和产品经理一起开SoS会议，同步团队开发中遇到的问题、障碍和风险。 第四，团队坚持Scrum的会议。并不断改进产品和团队一起的工作方法。 以上就是京东途牛融合项目的案例分享。3个案例已经全部分享完了。 -——————————————————————————————————— 下面重点来了，当当当当！来说一下京东的敏捷软件开发的精髓。这就是一个核心，四个基本点。 一个核心：价值驱动 四个基本点：透明、迭代、持续改进、教练 价值驱动 不以价值驱动为导向的敏捷转型就是耍流氓。我见过很多团队要进行敏捷转型，而如果你要问他们为什么要敏捷，则答案是五花八门。老板的要求，听说敏捷能让我们效率提升，质量提高。也有很多负面的声音，敏捷不适合我们团队，我们公司文化和敏捷不匹配，敏捷就是加班，等等。这些都没有回答到点子上。 而敏捷软件开发的精髓就是尽早频繁的交付商业价值（感谢Alistair Cockburn博士）。任何不以价值驱动的敏捷软件开发都是伪敏捷。那说了这么多价值驱动，以价值为核心，具体到实践层面要怎么做呢？ 这里我给大家介绍一个非常非常有用而且简单的工具—产品列表（Product Backlog）。团队敏捷转型，在接受了普及培训之后，第一个要做的事情就是建立一个且是唯一的产品列表。为什么要这么做？最重要的原因就是需求统一入口。
2015/9/2
articleCard.readMoreScrum教练静修报名接近尾声啦--Scrum联盟赞助主办
2015年9月更新 Scrum教练静修活动（Retreat）已经报名41人，每个人都是非常有经验的敏捷教练，而且他们来自10个不同的国家和地区，分别是中国、香港、台湾、巴西、澳大利亚、德国、美国、印度、日本、泰国。想要来和高手过招吗？ 活动详情 报名链接 2015年7月 Scrum教练静修活动通知：重大消息，早鸟名额只剩下少量的几个，如果想参加的同学需需要抓紧啦。 另外，为了达到静修的目的，整体参与者数量限制在75人，并且为了更好的多样性，每个企业限报名3人，超过3人将进入等待名单，在静修活动前2周将通知等待名单的结果。 什么是Scrum教练静修？ 静修不同于训练营、聚会、开放空间或者大会。这是一群更深层次以及更有经验的小规模的群体。静修的目的（愿景）是营造一段时光，通过有意义的方式，大家可以专注于学习和成长。以全新的视角，远离烦嚣，深度思考并共同协作的空间。 这次活动将于9月17日-9月19日在上海浦东香格里拉大酒店举行。有兴趣的小伙伴们可以抓紧时间报名啦，早鸟票价数量有限哦。早鸟价450美元。普通票价550美元。 活动链接：https://www.scrumalliance.org/courses-events/events/coaches-retreats/2015/scrum-coaching-retreat-china 报名链接：https://www.regonline.com/Register/Checkin.aspx?EventID=1722484 这里是2014年亚太区Scrum教练静修的结果，里面充满有意思和有意义的结果： https://coachesretreatthailand.ning.com/
2015/7/3
articleCard.readMore折飞机-团队建设游戏-敏捷游戏
游戏准备 游戏道具： 白纸若干，折好的飞机一个，折飞机文档一份（见12种折飞机的方法） 游戏目标：在8分钟时间内，每个人按规定折好一个纸飞机。 参与人员： 3个小组，每组5~9人 游戏步骤 第一组——文档：组员拿到一份文档，按文档说明制作纸飞机； 第二组——反向工程：组员得到一个已完成的纸飞机，他们要重现制作纸飞机的步骤。 第三组——指导：“首席设计者”按步骤制作一只纸飞机，而组员重复完成每一步。 结果 在在一系列有趣的试验中，让大家理解在敏捷项目中传递知识的最佳途径。实验结果如下： 在限定时间内， 只有12.5%的人能够按照文档完成任务。 使用反向工程方法，有25%的参与者成功做出飞机。 采用教练指导方法，则可以让100%的参与者全部成功做出飞机。 结论 健康的沟通和指导，是传递和分享知识的最佳方式。对于需要经常沟通和反馈的软件开发来说，这个原则更具价值。 补充 假如我是一个开发人员，我发现了一个技巧，可以将一些数据绑定到某个用户界面里的控件中，而且写出了代码实现。这个技巧构成了一种模式，与我一起开发的同事们希望了解具体做法。 如果你是我的同事，有三种方法： 我给你一个说明该技巧的相关文档； 我告诉你代码在哪里，建议你自己弄明白； 我跟你结对编程，通过一组新数据实现该模式。 你会选哪一种？ 反思： 将某种情形下的知识从一个单位（可以是个人、团队、部门、组织）传递到另一个单位，这就是知识传递。 很多组织用了很多时间将自己积累的知识记录成文档，希望知识传递过程能由此变得更顺利、高效。而敏捷并不鼓励文档，它强调“可工作的软件胜过面面俱到的文档”。 ——-12中飞机的折法—————- (https://www.360doc.com/content/12/0324/23/2567933_197411378.shtml) 12种折飞机的方法
2015/7/3
articleCard.readMore幸福的笑脸
游戏收益 小伙伴们，你想通过游戏学习精益理论吗，尤其是精益的核心，拉动式生产。通过这个简单的游戏，你可以学习到： 假设预测时长及预先规划的经济问题 看板原则——看板的核心是什么？ 现金流和投资回报的重要性 时长：60分钟 物料 每组4-6人 （一共5组） 每组50张蓝色和黄色的纸（A4大小或略小） 每组2个胶棒 每组3把剪刀 每组1卷美文胶带 游戏步骤 我们在经营一家制作纸笑脸的公司。这个笑脸包括： 椭圆形的蓝色脸蛋 2个三角形或长方形的黄色眼睛 1个三角形或长方形的黄色的嘴巴 我们一共有4种类型的产品： The Mike张三 – 三角眼，三角嘴 The Don李四 – 长方眼，长方嘴 The Aleem赵五 – 三角眼，长方嘴 The Jessica王二麻子 – 长方眼，长方嘴 第一轮——推动模式 每个组预先猜测一下上述类型的笑脸，市场分别会需要多少，悄悄地写下这些数字（不要告诉其他组）。小组根据这个猜测设置自己的流水线： 用蓝色的纸裁剪椭圆形脸 画上眼睛和嘴巴（必须的步骤） 粘上眼睛 粘上嘴巴 把做好的脸贴在墙上（交付） 在开始之前每组至少先做一个脸熟悉一下。这一轮4-5分钟。结束后，揭秘市场需要的实际订单数量。每组根据订单数，按照下面的指示计算纯利润： 每个做好的且卖出去的脸 = 400元 每个做好的但没卖出去的脸 = -200元 每个半成品的眼睛 = -25元 每个半成品的嘴巴 = -50元 每个半成品的脸 = -100元 有的组可能会赚了一点钱，但大多数都会是赤字或破产了。讨论一下这个业务模型，以及这种生产业务和库存会发生什么。
2015/6/30
articleCard.readMore幸福的笑脸
游戏收益 小伙伴们，你想通过游戏学习精益理论吗，尤其是精益的核心，拉动式生产。通过这个简单的游戏，你可以学习到： 假设预测时长及预先规划的经济问题 看板原则——看板的核心是什么？ 现金流和投资回报的重要性 时长：60分钟 物料 每组4-6人 （一共5组） 每组50张蓝色和黄色的纸（A4大小或略小） 每组2个胶棒 每组3把剪刀 每组1卷美文胶带 游戏步骤 我们在经营一家制作纸笑脸的公司。这个笑脸包括： 椭圆形的蓝色脸蛋 2个三角形或长方形的黄色眼睛 1个三角形或长方形的黄色的嘴巴 我们一共有4种类型的产品： The Mike张三 – 三角眼，三角嘴 The Don李四 – 长方眼，长方嘴 The Aleem赵五 – 三角眼，长方嘴 The Jessica王二麻子 – 长方眼，长方嘴 第一轮——推动模式 每个组预先猜测一下上述类型的笑脸，市场分别会需要多少，悄悄地写下这些数字（不要告诉其他组）。小组根据这个猜测设置自己的流水线： . 用蓝色的纸裁剪椭圆形脸 . 画上眼睛和嘴巴（必须的步骤） . 粘上眼睛 . 粘上嘴巴 . 把做好的脸贴在墙上（交付） 在开始之前每组至少先做一个脸熟悉一下。这一轮4-5分钟。结束后，揭秘市场需要的实际订单数量。每组根据订单数，按照下面的指示计算纯利润： 每个做好的且卖出去的脸 = 400元 每个做好的但没卖出去的脸 = -200元 每个半成品的眼睛 = -25元 每个半成品的嘴巴 = -50元 每个半成品的脸 = -100元 有的组可能会赚了一点钱，但大多数都会是赤字或破产了。讨论一下这个业务模型，以及这种生产业务和库存会发生什么。
2015/6/30
articleCard.readMore《引爆点》读后感 - 格拉德威尔系列
简介 作者: 【加】马尔科姆•格拉德威尔（Malcolm Gladwell） 出版社: 中信出版社 副标题: 如何引发流行 译者: 钱清 / 覃爱冬 出版年: 2014-4 页数: 288 定价: 36.00元 装帧: 精装 丛书: 格拉德威尔经典系列 ISBN: 9787508635736 《引爆点-如何引发流行》这本书中的核心观点：流行的三法则（即引爆观点） 个别人物法则 附着力因素法则 环境威力法则 我对于书中的观点进行了精炼，流行的三要素是：人、信息和环境。请参考下面的思维导图： 个别人物法则（人）（Law of the Few） 在人这个层面，作者把观点的传播者分为三类： 联络员 内行 推销员 联络员（Connector） 联络员是那种有着极广人脉的人，他们几乎和所有人都认识，并且是许多不同领域的。书中的例子是保罗*里维尔，是他把英国人要开战的消息传到了波士顿的北部，使民兵有了准备从而打响了美国的独立战争。 书中继续提到了2个概念：六度空间和微弱关系。六度空间指的是你和世界上的任何一个人只需要通过6个人就可以互相认识。（注：随着互联网的发达，六度空间慢慢变成了五度空间）微弱关系，书中的例子是找工作。大部分人找工作是通过这种微弱关系（只听说过某人，就可以获得一次面试机会并有可能入职）。 内行（Maven） 内行指的是对某一领域非常精通，发表的观点非常有说服力。虽然看起来内行不如联络员认识的人多，但是内行的影响力是一流的。因为他们对于你的产品，或者消息，了解的非常透彻。想一下，你在买车或者买房的时候，有没有受到旁边同事的影响？有可能他们就是你身边的内行。 推销员（Salesman） 推销员是极具感染力的，可以用任何方式说服你来购买（或相信某事）的那些人。这个是需要有天赋的。书中采访了一名推销高手-汤姆*高，他的特点是说话抑扬顿挫，喜欢为客户着想，有朝气、热情、魅力、可爱。认为“世界上没有不可能的事情”，并愿意去尝试。 附着力因素法则(Stickiness Factor) 想要信息得到推广，信息本身需要有包装或者叫做易于传播。比如书中给出“直销员旺德曼的金盒子”这个例子，就是设计一个对于客户的触发器，让客户看到信息后可以采取行动。这个可以设计到课程当中去。（后续采取行动）后面的《芝麻街》和《蓝狗线索》也是差不多的例子，通过反复的实验，找出最适合小朋友的电视节目。 环境威力法则（Power of Context） 书中提到两个重要的事情：破窗理论和邓巴数字。
2015/6/28
articleCard.readMore敏捷需求游戏
游戏目标 这个游戏的目的是让“开发团队”根据“需求团队”写的书面需求文档创建一幅图形。 游戏步骤 每组对半分成2个小组。一半是“开发团队”，另一半是“需求团队”。最好是2个小组能地理上分开。比如一个小组在屋外，另一个在屋内。（注意：分组的时候可以让原来写需求的人做开发，而不写需求的人来写需求） （开发团队到屋外休息）需求团队留在屋内，给他们展示一幅图形。然后让需求团队在10分钟内根据图形写出需求。 需求写好之后，开发团队进屋，需求团队到屋外休息。（注意：开发团队和需求团队的成员要一一对接，即找到自己的接口人） 开发团队根据写好的需求进行开发，时长10分钟。开发团队如果对于需求有问题，可以给需求团队写邮件沟通（写好之后由引导师送信）。写信的内容只能是文字沟通，不能用图形，数字或者符号。 需求团队和开发团队不能进行口头沟通或者暗示等。 所有的需求必须是以文字形式描述。不能用图形，符号或数字。 需求文档要求尽可能的详细。 开发团队完成后，大家一起评审结果。 原文：https://www.bigvisible.com/2010/11/spec-writing-game/
2015/6/23
articleCard.readMore老板和走路人的游戏（boss walker）- 敏捷自组织团队游戏
这个游戏一共分两轮 第一轮 两人结对 一人是老板，另一人是走路人 老板负责给出指令：走，停，左，右，快，慢 走路人必须遵守老板的命令 老板负责保证走路人在60秒内完成60步 走路人负责数步子 老板可以命令走路人，但不能有身体接触，也不能帮忙 不能站在原地，必须结对行动 必须在房间内 第二轮 老板也要参与到走路的过程，即老板也变成走路人 走路人自己负责找出如何走60步 限定时间30秒 其他规则同第一轮 总结 这个是一个非常简短而有力的游戏，快速地体会命令控制和自组织团队的差别。总结的时候可以结合Richard Hackman写的《Leading Teams》里面授权矩阵，介绍自组织（自管理）团队的职责，以及自指导和自统治团队是什么样子的。
2015/6/19
articleCard.readMore老板和走路人的游戏（boss walker）- 敏捷自组织团队游戏
这个游戏一共分两轮 第一轮 两人结对 一人是老板，另一人是走路人 老板负责给出指令：走，停，左，右，快，慢 走路人必须遵守老板的命令 老板负责保证走路人在60秒内完成60步 走路人负责数步子 老板可以命令走路人，但不能有身体接触，也不能帮忙 不能站在原地，必须结对行动 必须在房间内 第二轮 老板也要参与到走路的过程，即老板也变成走路人 走路人自己负责找出如何走60步 限定时间30秒 其他规则同第一轮 总结 这个是一个非常简短而有力的游戏，快速地体会命令控制和自组织团队的差别。总结的时候可以结合Richard Hackman写的《Leading Teams》里面授权矩阵，介绍自组织（自管理）团队的职责，以及自指导和自统治团队是什么样子的。
2015/6/19
articleCard.readMore《异类》读后感 - 格拉德威尔系列
作者: 马尔科姆•格拉德威尔 出版社: 中信出版社 副标题: 不一样的成功启示录 译者: 苗飞 出版年: 2014-5-1 页数: 264 定价: 36.00元 装帧: 精装 丛书: 格拉德威尔经典系列 ISBN: 9787508643946 昨天花了一天的时间看完了《异类》这本书，有不少收获。总结一下： 书中把成功人士归类为异类，因为他们与众不同。而这些成功人士都是天时地利人和的环境下产生的。 天时 书中开篇提到的是加拿大冰球队球员的出生月份，80%的球员都是1,2,3月出生的。而原因是球队的注册日期是每年的1月1日，也就是说1月1日出生的孩子，在达到年龄后（且成绩合格的话）可以入选球队，而他比同龄但12月出生的孩子几乎大了整整1岁。在10岁以下12个月的时间对于生理心理都会有极大的影响。 我的反思：出生日期不在范围内的孩子，由于无法入选而错过了优秀教练和环境，因此在接下来的10年内也会缺乏10000小时的不断练习，从而错过了成为异类的机会。那么如果我的孩子很喜欢某项运动，我会想尽一切办法让他去最优秀的环境去。（参考作者的后记：故事来自牙买加） 地利 本书中还从地理位置来解释为什么有哈伦小镇这样的世仇，为什么中国的稻田文化有利于数学。地域文化对于一个人的影响非常大。书中一开篇在引言中就提到罗塞托之谜，以及现在硅谷中的大部分财富掌握在犹太人手中。这些事实都说明了一个良好的地域文化对于成功太重要了。针对这点，我能做什么呢？思索中，暂时还没有答案。 人和 人和，指的就是与人打交道（或者说公关）能力。不论碰到什么事情，都可以大事化小，小事化无。 最后，从这本书中，总结最大收获的两点是： 10000小时刻苦练习。在教育儿子方面，第一步陪他一起找到兴趣，第二步就是提供足够好的优良的环境，来进行10000小时练习。 情商。在中国有句古话说，“女儿富养，儿子穷养。”而这本书的理念是不论女儿儿子都要富养，带他参加各种活动，让他从小就明白这个社会的规则是什么，如何利用社会规则为自己争取到利益。
2015/6/18
articleCard.readMore快速有效敏捷估算 - 如何在一小时内把200多个需求进行估算和排优先级
在前一篇敏捷估算中，介绍了估算的最最重要的目的是达成共识。而实际上我们除了这个最重要的目标，还需要根据需求的规模（估算值）和价值来进行产品列表的排序。 下面介绍一种快速有效的方式，可以在短时间内把大量的需求进行估算并排好顺序。这种方法基于前一篇敏捷估算中的第二种方法 – 即三角估算法而改编的。 这种方法一共分为两大步： 估算需求规模 估算需求价值 整个过程需要由产品负责人来协调和做准备工作。这两步可以分别邀请不同的参会者，第一步需要开发团队的参与，而第二步需要客户的参与。 0. 准备工作 首先需要有一面足够宽的干净的墙 把所有的需求提前打印好，或者抄写在报事贴上 报事贴 记号笔 1. 估算需求规模 第一步，估算需求规模需要邀请开发团队参与。需求的规模用故事点来描述。具体的操作方法可以参考敏捷估算中三角估算法。最后的结果是所有的需求从左到右排成一条线，左边是最小的，右边是最大的。如下图： 2. 估算需求价值 第二步估算价值的时候，需要邀请客户来参与。要先对客户解释这面墙的作用，客户只需要根据每个需求的价值来上下移动卡片，最上面是价值最大的，最下面是价值最小的。如下图： 最后的结果 最终，所有的需求可以分成四个象限。左上角，较小的且价值很高的需求，需要马上去实现。右上角，较大的而价值很高的需求，需要考虑需求拆分。左下角，较小但价值很小的需求，可能会随着时间的推移而忽略掉。右下角，较大且价值很小的需求，随着时间推移，需要不断优化提炼以发现其中的价值。或许会移除掉，或许会随着价值变化而改变顺序。
2015/5/31
articleCard.readMore敏捷软件开发中的架构设计
前言：本文主要从软件开发的架构设计根源、以及敏捷软件开发中如何做架构设计两个方面来进行阐述。 架构设计的根源 架构一词来源于建筑业，指的是“一个结构内的元素及元素间关系的一种主观映射的产物”。而软件开发是一个新兴产业，在高速发展的同时也在学习借鉴其他行业经验。架构就是软件开发学习建筑业的产物。这个学习（或参考、或借鉴）是完全错误的，软件开发和盖楼是完全不同的两件事情。软件开发是脑力工作（知识工作），是一件复杂的事情。而盖楼是体力工作，是一件繁杂的事情。如果说要和建筑业进行学习借鉴的话，软件开发的过程和设计建筑蓝图（blueprint）是具有相似之处的。因此为了更好的响应变化，软件开发不适合采用整体预先的架构设计。 软件开发是一个持续学习、不断反馈的过程。 软件开发的目的是为了产生可工作的软件，是为了解决一些人的问题。而这些问题是来自一个人的头脑中，如果想要知道一个人是怎么想的，就必须要持续沟通（学习），不断地和这个人进行反馈。这才是软件开发的本质。 敏捷软件开发中的架构设计 与软件社区的某些讨论相比，敏捷开发并非要求像船货崇拜那样热衷于Scrum或其他过程和方法学。敏捷的本质是响应变化、持续学习和不断反馈。敏捷表现为软件及其开发过程的可持续和高质量。敏捷原则中写道“坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强”，这为架构指明了敏捷开发中扮演的角色——无需大量预先设计。 架构只是一种知识的表达方式。软件开发作为一项知识性工作，需要学习技术、学习客户需求，学习和提出产品需求的人交流，学习从设计实践中选取最佳方案，学习合作等等。总而言之，知识源自学习，学习需要时间，而时间正是过程的组成元素。 因此在软件开发的一开始，我们对知识（或需求）了解的最少，这个时候如果进行全面完整的架构设计，往往是基于大量的假设和猜想，做出的种种重大决策也是不明智不理智的，是百害而无一利的。在软件开发结束的时候，信息是最丰富的，我们了解的知识也是最全面的，但此时做决策已然晚了。所以架构设计也是一个基于经验的活动，在持续学习和不断反馈的过程中，不断地检视和调整。 最后，送给痴迷于全面整体的架构设计朋友们一句话：“软件开发的目的是尽早频繁地交付客户价值。”
2015/5/30
articleCard.readMore敏捷估算--Scrum系列
本文谈及的均为Scrum中的估算行为，这些方法不是Scrum原创的。 为什么要估算 谈估算，我想先从为什么要做估算谈起。 每次在我的培训课上，学员们会给出各种各样的答案。比如为了估计成本、为了设定发布日期、为了知道什么时候可以做完、为了……。但我认为估算最重要的目的是为了 达成共识 如果没有进行估算，关于需求或任务会有一些假设或者背景被忽略掉。因此在Scrum中，估算是一个集体行为，而不是某个专家拍拍脑袋出来的结果。 如何做估算 估算的方式分为两大类，绝对估算和相对估算。绝对估算耗时更长，并且需要依赖上下文，最后的结果也会产生较大误差。而与之相对，相对估算更快，结果容易达成一致。Scrum中对产品列表（product backlog）的估算常常使用的就是相对估算，估算单位为故事点（没有意义的单位）。【注意：不要将故事点和小时数做一一对应！】最常用的方法就是计划扑克。 计划扑克是由斐波那契数列组成的一串数字扑克，如下图： 对产品列表条目（product backlog item）进行估算的步骤，简单描述如下： 首先估算需要开发团队所有成员参加，每个人手里有一套上图的扑克 取出一个产品列表条目，产品负责人进行描述 每个团队成员根据自己的理解，拿出一张代表估算值的扑克并扣着放在桌面上。（这个过程不要讨论，不要说话，不要把你的结果告诉其他人，具体原因参见百度百科“锚效应”） 所有成员出牌完成后，大家同时亮出自己的结果 接下来邀请估算最小的成员解释一下原因，还要邀请估算最大的成员解释一下原因。讨论过程中注意遵守团队礼节。 解释完毕后，重复步骤3到步骤5，直至最后大家的估算结果一致。 相对估算还有另外一种方法，称为三角估算法。 从产品列表中挑选一个较小但不是最小的条目，比如条目A，并设定它的估算值为3 （故事点） 从产品列表的最上面取出一个条目B，和A进行对比。如果比A大，放在A的右边。如果比A小，放在A的左边。如果和A差不多大小，放在A的下面。 继续从产品列表取出条目C，重复步骤2，分别和条目A与条目B进行比较。直到为条目C找到合适的位置。 重复步骤2和步骤3，直至所有的产品列表条目都完成放置。 比较一下A左边的产品列表条目，估算值为2还是1，把左边的所有条目估算值设置为2或1.同样的把A右边的条目，按列标明估算值。 最后的结果如下图： Scrum系列： Scrum系列之Scrum起源 Scrum系列之Scrum框架 Scrum系列之Scrum角色 Scrum系列之Scrum会议 Scrum系列之Scrum工件 Scrum系列之Scrum需求梳理 Scrum系列之Scrum估算
2015/5/14
articleCard.readMore成都敏捷驴友聚会感受--记敏捷之旅全国组织者第二次聚会
会议中 说几个聚会当中，我印象最深刻的人和事吧。 侯伯薇 我最需要感谢的人是侯伯薇！在14日上午开场的时候，面对60人的大场面，我hold不住啦，不知道如何能让大家静下来。就在这个时候侯伯薇站出来了（黄继光炸碉堡~~）！全天的过程当中，他很好地帮忙维持秩序，整个聚会有效的推进并圆满结束。 反思：开场时我尝试用铃铛让大家安静，但声音是此起彼伏，慢慢的大家对于铃声免疫了。后来侯伯薇做了什么呢，为什么他打铃就能够安静下来？他走到说话的人面前，打铃，“请安静”（说话）；然后走到下一个说话的人面前，重复上面的动作，打铃，“请安静”（说话）。很快全场就安静下来了。 张林 听张林聊天是一种享受！尤其是这次听到一个全新的角度看待互联网（信息时代）的故事。在信息时代之前，也就是没有互联网的时候，人与人之间是物理连接，是有空间感的。随着信息时代的到来，比如2000年左右，很多公司有了自己的网站。这就像物理时代，一个公司开业挂牌了。慢慢的，有了个人博客。这个好比物理时代，每个人有个身份证（或者门牌号）。继续深入挖掘，大家最痛恨中国互联网的是什么？（我猜有许多人会说GFW吧）这个对应到物理时代是什么呢？（我想到的清朝末年闭关锁国。。。）好了，不多说了，慢慢体会吧。 滕振宇 滕振宇是我的偶像！虽然这次聚会上没有很多交流，针对14日上午我的引导过程，他给出了很明确的反馈。在制定聚会基本规则（Ground Rule）的时候，我引导大家说出规则。结果是，当听到铃声时，“听Bob说话”。而当时我的回馈是，“这不是我想要的规则。。。” （太典型的反面案例了~）规则是谁的？滕振宇给我如上的反馈。是啊，看了这么多引导的书，也练习过很多，犯了这个错误实属不应该。 反思1：在说“这不是我想要的规则”时，我是带着情绪的。因为之前大概5分钟，我都无法控制场面，有些气馁。后来想了一下，大家的反馈“听Bob说话”是有开玩笑的意思的，我完全可以顺着这个方向，把规则明确细化，并和大家确认。比如，– 看来大家还想听我说话的，谢谢大家！那么我们在听到铃声后，马上举起双手，停止说话，看着说话的人，并听Bob说话。这个是大家刚才说的规则吗？（得到反馈后）那么有谁对这个规则有疑问吗？（如果没有疑问，可以把规则写在白板纸上） 反思2：针对白板纸，或者说可视化这个事情上，我是可以改进的。1. 上面提到规则可以写到白板纸上，这样每个人都能看到并提醒大家。2. 日程安排可以提前准备好，并写到白板纸上。即使是错误的也没关系，让参会者知道整个会议的框架是必须要做的。 文开琪 文开琪是我心目中的大人物！自从我参加敏捷社区活动，就听说过文老师，并且最近几年文老师一直是默默的支持着社区活动！图书赞助敏捷之旅、精创周末、ScrumGathering等活动。后来也很有幸能和文老师一起合作翻译《Scrum精髓》这本书。这次聚会上，文老师也给了我很多启示。这么多年的中国敏捷社区，都是吸收国外的优秀经验，照搬国外的好东西。中国敏捷社区有没有自己的一些内容可以出版呢？ 会议后 其实我是个懒人，这次聚会之后我也没有想到要总结的。不过看到了Kelvin同学的总结激起了我想写点东西的欲望。 谢谢Daniel的转发，谢谢Kelvin同学的文章。是你们让我“不要脸”的分享我的一些体会~~
2015/3/19
articleCard.readMore产品经理入职后要烧的12把火
一个产品找到了自己的主淫，不论你新加入了一个小创业公司，还是你在大公司中发起一个新的项目，头30天决定你的成败。 如何在第一个月内找到入口，请参考以下建议。重点在于团队、产品、自己： People团队 与你的老板达成一致的、明确的目标。 一个萝卜一个坑儿，你的身上已经背负了要立刻向组织作出贡献的压力。回顾你与老板的共同目标，确保他对你的期望值不偏不离不高不低。你第一个月的任务就是要真正的融入一个团队。 和团队的每个成员来次一对一的谈话。 短则几小时，长达一个月，根据团队的大小而定。但一定要抽出时间和每个人单独约见。 我更喜欢俩俩单独散步——当两个人走在一起的时候，我们共同“向前望去、展望未来”而不是在会议室桌子的两头盯着对方。这本身就是鼓舞振奋的。 询问每个人“我能为你做点什么吗？” 你在这是为了帮助大家，而不是命令大家。他们的答案可以真实地反映他们如何看待产品经理这个角色，以及他们需要你做什么。 为其他组员做些什么 期望你能从谈话中找到一些可以让你立刻上手并有效提高团队工作效率的事情。也许工程师想让你把BUG分类，或每周帮大家去超市采购。 Product 产品 与你的首席工程师约时间，非常详细的过一遍产品的技术架构 不耻下问，但也没必要太纠结于没意义的小细节。 产品经理总是想以自己敏锐的技术嗅觉给工程师们留下深刻的印象。但以我的个人经历，能够提出问题并说出自己哪里不明白的产品经理更受工程师欢迎。 刚入职，低调、低调 你想要开始改进产品或开发流程。我建议你先缓缓。 在你真正奠定了自己的地位、得到认可、了解所有细节之后，你的建议才更容易被接纳。现在你也可以证明你是一个很好地倾听者。 靠近用户 在你刚入职的初期，好好花点时间与你的用户多多交流。做些电话销售以及客户访谈。找找用户需要怎样的支持服务。多和用户在论坛、微博、微信平台上进行交流。 搞点技术呗 我坚信产品经理应该是技术型人才，并且一个绝佳的切入点应该是自己搞定一个BUG或为产品“锦上添花”一个新特性。 建立一个开发的氛围，争取做一些力所能及的小事。但同时要考虑好自己以及团队的时间安排。归根结底你是产品经理而不是全职开发。 Personal 个人管理 读，甚至自己写 读任何可以让你对业务上手的东西——以前的绩效考核、说明书、设计文档、百度百科。当你发现文档缺失或失效时，自己来写。花时间把你已经学到的以及未来可以改进的东西写下来，为你的下一份工作累计经验。 制定个人目标 换工作可以让你感到有些自豪，但又有些无能为力。现在有机会让你就个人发展制定一些目标。简单说两句： 有没有一件你做的非常好的事，并且你愿意继续做？你要如何养成做这件事的好习惯？ 有没有一件事你需要改进？你将如何改进，并且你如何最自己的改进过程进行评估？ 欲做其事，必善其后。 备好所有工具、设备。装好所需软件。设置邮件过滤系统。接收各种关于你的产品以及竞争对手产品的新闻推送。 玩好！ 原文链接：https://www.gv.com/lib/12-things-product-managers-should-do-in-their-first-30-days-at-a-new-company 感谢我的同事彭晓溪进行翻译~
2015/3/16
articleCard.readMore商业模式画布
商业模式画布 商业模式画布图来自于《商业模式新生代》一书，是一个用于阐述、分析和设计商业模式的实用工具。 它由9个模块构成，每一块都是一个成功的商业模式的重要构建部分，包括：客户细分、客户关系、渠道通路、价值主张、关键业务、核心资源、重要合作、成本结构、收入来源。 商业模式画布的9个模块介绍 客户细分 企业或机构所服务的一个或多个客户分类群体。 客户关系 在每一个客户细分市场建立和维护客户关系。 渠道通路 通过沟通、分销和销售渠道向客户传递价值主张。 价值主张 通过价值主张来解决客户难题和满足客户需求。 关键业务 ……通过执行一些关键业务活动，运转商业模式。 核心资源 核心资源是提供和交付先前描述要素所必备的重要资产…… 重要合作 有些业务要外包，而另外一些资源需要从企业外部获得。 成本结构 商业模式上述要素所引发的成本结构。 收入来源 收入来源产生于成功提供给客户的价值主张。 使用阶段 商业模式画布可以用于几乎所有的商业领域。对于已经在运营的企业或机构，它可以帮助明晰企业核心目标，同时明确其优点、缺点和首要任务，发现现存问题并及时制定策略。刚起步的公司可以利用商业模式画布图来设计、模拟创新的商业模式。除此之外，也可以通过画布图来分析其他成功的商业模式，取其精华。 使用步骤 1、 确定参与创作的人6-10个，首先让大家描绘企业所服务的客户细分市场。参与者根据客户细分群体的不同，将不同颜色的便签贴在画板上。每组客户代表一个特定的群体，他们有特定的需求，而你得向他们提供特定的价值主张，或是他们需要不同的渠道、客户关系或收入来源。 2、 描述企业对每个客户细分群体的价值主张的理解，即反映出每个客户细分群体的价值主张。参与者应当使用相同颜色的便签代表每个价值主张和对应的客户细分群体。如果一个价值主张涉及两个差异很大的客户细分群体，那么应当分别使用这两个客户细分群体对应颜色的便签。 3、 使用便签将该商业模式中所有剩余模块标示出来。相关客户细分群体始终坚持使用同一颜色的便签。 4、 映射出整个商业模式后，开始评估该商业模式的优劣势。将绿色（代表优势）和红色（代表劣势）的便签分别贴在商业模式中运行良好的模块和有问题的模块旁边。 5、 将评估后的商业模式再进行整体的调整，多次迭代完善后可以将各模块元素用图形化元素表达出来。 商业模式画布模板 自提柜如何盈利的商业模式画布
2015/2/28
articleCard.readMore产品列表梳理（需求梳理）--Scrum入门基础系列
产品列表梳理会议是Scrum中非常重要，而很容易被忽略的一个会议。说它重要，是因为Scrum开始之前就需要有准备就绪的输入，这个输入就来自于产品列表梳理会议的结果，即初始的产品列表。而对于刚开始转型敏捷的团队，往往会忽略掉产品列表梳理会（需求梳理），从而造成迭代计划会时间过长，或者无法准时开始迭代等等问题。要想解决这个问题，需要首先明确为什么在迭代开始之前要进行梳理会议，以及谁需要参加这个会议，在这个会议都有哪些活动等。 产品列表梳理会议，是迭代就绪的很好的指示，即只有产品列表准备好了，才可以进入迭代。另外，梳理会议是由产品负责人发起或负责，可以召集开发团队参与，也可以只有相关的开发团队成员或相关的利益干系人参与。 产品列表梳理会议的内容可以总结为如下几个字：增删改。首先需要明确一点的是产品列表不是固定不变的，它是可以随着新需求的出现而变化的（即好的产品列表符合DEEP原则，参加博文产品待办列表和用户故事）。 增：那么当出现新需求的时候，就需要增加一条产品列表条目，并且针对新的条目也需要符合良好用户故事的标准（INVEST）。 删：某条需求如果已经不再需要，或者市场条件变化后该需求就可以删除了。 改：产品列表的修改还可以分为以下几类： 重新估算用户故事大小、 重新排用户故事的顺序、 用户故事拆分等。 调整发布计划 Scrum入门基础系列： Scrum入门基础系列之Scrum起源 Scrum入门基础系列之Scrum框架 Scrum入门基础系列之Scrum角色 Scrum入门基础系列之Scrum会议 Scrum入门基础系列之Scrum工件 Scrum入门基础系列之Scrum需求梳理 Scrum入门基础系列之Scrum估算
2015/2/23
articleCard.readMoreScrum工件-Scrum入门基础系列
Scrum工件主要包含一下3种： 产品Backlog Sprint Backlog 产品增量 产品Backlog 在Scrum中，主要由产品负责人[参见Scrum入门基础系列之Scrum角色]整理和维护产品Backlog。产品Backlog是Scrum中维护需求的主要工件，也是做好Scrum的第一步。一个好的产品Backlog，是要符合DEEP原则的，即，产品Backlog是详略得当的（Detailed Appropriate），涌现的（Emergent），估算的（Estimated）和排序的（Prioritised）。详情参考参考之前我发的博文“产品Backlog和用户故事的原则”。 一般来讲，产品Backlog里面都可能包含哪些内容呢？新特性、改进项、缺陷修复、文档需求等。 Sprint Backlog Sprint Backlog主要由挑选的当前Sprint要完成的产品Backlog条目，以及根据这些条目进行拆分后的任务组成的，在Sprint Backlog中还有一个很重要的东西就是当前Sprint的目标，团队根据这个目标以及产品Backlog的排序来进行挑选。 Sprint Backlog的内容是由团队来决定的，具体的工作方法和实现方式，也是团队自己来决定的。在这一点上，充分体现了团队的自组织能力。 产品增量 产品增量是Scrum中非常重要的工件，因为产品增量才是最终交付给客户的内容。因此每个Sprint团队必须交付产品增量，以符合如下原则： 交付的产品增量必须是高质量的。也就是说每个产品增量是潜在可以发布的。 交付的产品增量符合团队的完成定义（Definition of Done） 产品负责人（或客户）能够接受产品增量 另外，产品增量也是团队进展的一个标识。开发团队通过不断地交付产品增量，给团队本身和利益相干人以信心，促使产品最终发布。团队进展还有其他常用的标识是燃尽图和任务板。一般使用燃尽图和任务板时，是为了使当前的进度公开给更多的其他团队或干系人。 完成定义，指的是当产品增量完成的时候，必须是团队成员共同理解的完成，而不会出现歧义。并且产品增量需要是高质量的，潜在可以发布的。也就是说，当产品负责人要发布当前的产品增量的时候，马上可以发布出去。完成的定义，是团队根据团队当前的情况，共同协商制定的，共同同意并理解的。还有，完成的定义也不是一成不变的，随着时间的推移，团队倾向于更加严格的定义，比如把更多的内容添加到完成定义中。 Scrum入门基础系列： Scrum入门基础系列之Scrum起源 Scrum入门基础系列之Scrum框架 Scrum入门基础系列之Scrum角色 Scrum入门基础系列之Scrum会议 Scrum入门基础系列之Scrum工件 Scrum入门基础系列之Scrum需求梳理 Scrum入门基础系列之Scrum估算
2015/2/20
articleCard.readMoreProduct Backlog Refinement
Here I would like to talk about product backlog refinement meeting, including what activities should be in this meeting, who should join this meeting and why we need refinement meeting. Why to have product backlog refinement meeting As the figure above, it occurs during sprint for product backlog refinement meeting, and normally no more than 5% total time of sprint. E.g during sprint 1, Product Owner (PO) will conduct refinement meeting for sprint 2 and sprint 3.
2015/1/5
articleCard.readMore探秘瀑布式软件开发的“错误起源”
最近一直在反思一个问题，那就是瀑布式软件开发的问题究竟出在哪儿了？这个问题首先要先问问瀑布式开发的鼻祖–Winston Royce，而看了Royce当年的论文之后，有不小的发现。其实他当时提出瀑布式软件开发就已经指出这个过程存在很大的问题，在论文中他提出，瀑布式开发中测试在很靠后的阶段才第一次介入（接触到软件），如果发现设计中（或需求上）的问题结果很严重。 论文的原文如下： 结果不言而喻，提出者已经质疑的一个理论，被无限放大了。 接下来从另外一个角度继续探究这个问题，即瀑布式软件开发是从哪儿学来的？我们很容易的可以从制造业的流水线工厂内找到相似的模型。针对制造工厂的生产环节，努力做到的一点是标准的（相同的）输入，经过流水线后，会产生标准的（相同的）输出。因此在输入的时候就要想尽办法要让内容保证标准。如下图，瀑布式软件开发也在做同样的事情。 所以在瀑布式软件开发中，首先要做的事情是尽可能的收集需求，收集的越多越好，越详细越好；接着就是做需求分析和设计，这个阶段也是追求完美，最后根据这些完美的详尽的文档制定出一份无懈可击的计划，然后开发团队按照计划执行就搞定了。 如果发生需求变更怎么办，有需求变更委员会。据我个人的经验，需求变更是很难通过需求变更委员会的批准的。因为瀑布式软件开发会认为我都已经做完设计了，这个时候变化会带来大量返工。所以越到后面的阶段，变更越难。 那么瀑布式软件开发有没有优点呢？下面我们看看瀑布式软件开发有哪些优点：【翻译自https://www.waterfall-model.com/】 在进入下一个阶段之前必须完成当前阶段的工作。因此如果该阶段有问题可以很容易的发现。 许多重要信息都留在纸面上。新员工进入项目时，可以很方便的知道进行到哪儿了。 瀑布式软件开发方法几乎所有的软件开发者都熟悉，也很容易采用。 最后，你怎么看呢？
2015/1/4
articleCard.readMore敏捷会议-Scrum会议-Scrum入门基础系列
Scrum会议包含Sprint计划会、每日例会、Sprint评审会、Sprint回顾会。下面分别介绍这几个会议，按照一个简单模板进行介绍： WHY、WHAT、WHEN、WHO、HOW，即为什么要有这个会议，这个会议的输入和输出是什么，什么时间开这个会，谁来参加，如何开好这个会议。 Sprint计划会 WHY Sprint计划会是为当前Sprint做计划的会议。 WHAT Sprint计划会的输入为产品Backlog，最新的产品增量，团队的能力和开发速率；输出为Sprint Backlog和Sprint目标。 WHEN Sprint计划会议发生在Sprint开始的时候。对于一个4周的Sprint，计划会时间应该小于8小时，2周Sprint，计划会时间小于4小时，以此类推。 WHO Scrum团队（产品负责人、开发团队、ScrumMaster）都应该参加Sprint计划会。 HOW Sprint计划会议有两种方式。 方式一：传统的两段式会议 - 第一部分由产品负责人和开发团队一起决定要完成什么（What），第二部分由开发团队来决定如何完成（How）。 方式二：循环式 - 1 产品负责人和开发团队选择产品Backlog最上面的那个用户故事，2 开发团队根据团队能力和以往的速率决定是否可以完成这个用户故事， 3 如果可以完成，那么拆分用户故事为任务，否则选择结束Sprint计划会议。4 重复上述1，2，3直到团队无法承诺更多的用户故事。 每日例会 WHY 团队每天同步信息 WHAT 团队会根据每日例会的情况，1. 调整燃尽图（如果有的话） 2. 调整Sprint Backlog或Sprint Backlog中的任务。 WHEN 强烈建议每天固定时间和地点开始 WHO 开发团队、ScrumMaster、产品负责人（可选）、其他利益干系人（可选） HOW 团队围成圈，面对彼此，回答如下3个问题：1. 从上次例会到现在我完成了什么？ 2.从现在到下次例会我将会完成什么？ 3. 有什么障碍或问题？在整个每日例会过程中，只有猪（隐喻投身Scrum的角色）才可以发言。 Sprint评审会 WHY 在Sprint结束前，产品负责人接收或拒绝开发团队的Sprint目标。团队检视和调整开发的产品增量。 WHAT 输入为Sprint目标和Sprint Backlog，输出为潜在可交付的产品增量和调整的发布计划。 WHEN Sprint结束前 WHO 开发团队、ScrumMaster、产品负责人、其他利益干系人（建议邀请，尤其是有关联工作的） HOW Sprint评审会是一个非正式会议，即这个会议上不需要准备幻灯片来进行完美的表演，团队需要展示出他们的工作成果。另外产品负责人应该不是第一次看到Sprint的成果，也就是说很可能在平时，开发团队每完成一个用户故事，产品负责人就已经评审一个。最后不过是一个仪式，可以让团队拥有成就感。 Sprint回顾会 WHY Sprint结束前，团队一起为开发流程做出改进而努力。 WHAT 输入为各类主观和客观数据，输出为行动计划，有可能放在专门的改进Backlog，也可能放在下一个Sprint的Backlog中。 WHEN Sprint结束前，一般在Sprint评审会之后。 WHO 开发团队、ScrumMaster、产品负责人。（一般不建议经理参加） HOW 设置环境 收集数据 产生洞察 确定行动 结束会议 具体细节请参考《敏捷回顾》一书（Agile Retrospectives）
2015/1/3
articleCard.readMoreO2O精益创业 High翻天工作坊游记
2014-12-21 黄喆 敏捷一千零一夜 记录者，黄喆，软件攻城狮，CSM，热爱敏捷、精益。目前工作于GE，从事软件过程改进、敏捷项目管理等工作。希望能在Agile1001这个大家庭中与大家交流、学习、共同成长。 -——分割线——– 600%现金人民币纯利收益；亲身经历组建创业团队、MVP产品设计、拉投资、虚虚实实的商业博弈、吸引天使客户的反馈、痛苦的产品转型、高大上的兼并和重组以及激动人心的现金分红；最后，还结识了一群激情四射、才华洋溢的队友！这么Fancy的事就发生在一个下午，三个半小时之内，而且还是免费的！您一定是在做梦吧？！！哈哈，绝对没有！这一切都发生在Agile 1001在敏捷之旅上为我们带来的“O2O体验式工作坊”中！笔者有幸参与其中，爽到之后不敢独享，还要分享出来让大家眼馋一下，从而再次提升一下自己的幸福指数。哈哈，太邪恶有木有。。。 废话不多说，咱们直奔主题，这次Agile 1001为我们带来的“O2O体验式工作坊”的主题是最近火遍全球的精益创业。但其采用的方式是纯体验式的，整个活动下来没有一句说教，就是一个字“玩儿”！参与工作坊的同学首先被随机的分成了3个小组，每个小组选出一名CEO负责创业公司决策和一名CPO负责产品设计。笔者非常幸运的被大家推选为了CEO，而来自“汽车之家”的刘阳 同学被我们推举为了CPO，这可能是我们做的第一个也是最正确的决定。至于当CEO为啥“幸运”，选CPO为啥“正确”，这个我们后面会说。 “家里菜团队” “来就吃”团队 俺们“微饭”团队，在讲的是CPO,我是。。。你们猜猜。 工作坊的游戏规则很简单：三个组的目标都是做一款餐饮APP，需要有自己的特色，总共三个MVP，每次交付一个纸面原型，然后选择是否发布给市场获取反馈（但同时也要承担竞争组针对性的打击），最终三个迭代后在三个组中PK出唯一的获胜团队。（不知道MVP和纸面原型概念的童鞋要赶紧补习一下啦，这里不解释喽）。之后就是这次工作坊的最大亮点，每个团队被要求进行一轮真金白银的创业集资，每位团队成员都必须拿出真的人民的币来进行这次集资，而最终在游戏中获胜的团队将会“席卷”另外两个团队的所有集资，然后按照股本比例分红！赤裸裸的零和博弈and真金白银的输赢啊！不要太刺激了有木有？！！在一番面面相窥的严肃思考后，大家小心翼翼的将自己热乎乎的人民币放到了团队集资袋中封好。然后，为了另外两个组的人民的币，我们义无反顾的踏上了激动人心的创业之旅。 下面来说说我们的“创业”历程。我们小组对这款餐饮App取名“微饭”，我们的CPO刘总和大家讨论后对“微饭”的定义是：实现客户的提前在线订餐，让食客可以到了就吃，在节省食客就餐时间的同时提高餐馆的翻台率。双赢！很不错的想法是吧？可后来的事实证明我们差点就在这里犯了最致命的错误，幸亏我们后面悬崖勒马，才避免了一出创业悲剧的上演。我们小组经历了一个Sprint的忙碌，终于满头大汗的做出了第一个MVP，团队成员一致决定向市场发布我们的产品，不畏竞争对手可能的针对，听取市场的反馈。另外的两个小组中“家乡菜 ”小组和我们一样选择了发布，另一个“来就吃” 小组则选择了隐藏自己的产品意图暂不发布。从这里开始一出狗血创业剧正式拉开了序幕！ “微饭”的第一次产品发布很炫很过瘾，但在礼节性的掌声后，围观群众全都作鸟兽散去，等等！说好的天使客户和用户反馈呢？没有反馈就失去了MVP的意义啊，这可不行！于是我们团队紧急开会，一起讨论如何才能激发用户的反馈。最终，在试了各种诱惑招数失败后，我们“机智的”向市场推出了“天使用户配股”政策：只要给我们提供反馈并被我们认定为有价值后，就可以获得微饭1%到5%的原始股权。也就是说如果我们组获胜，天使用户就可以按照比例参与分红。这招果然有效！ 立杰和伟忠老师都来给我们提出了建议，立杰老师的建议非常劲爆，他告诉我们原来我们这个提前定餐的“好主意”早已经被大众点评实现了，但事实证明这个提前定餐的模式中国人并不受用，没有太多人喜欢提前定餐，而这个产品定位的失败也导致了大众点评最近的IPO失败，大量员工流失，境遇岌岌可危！天，我们差点犯了前人已经犯过的错误，这反馈很有价值啊！伟忠老师的反馈则相对正能量一些，他认为我们的产品特点不突出，没有清晰的产品定位，建议我们简化产品突出一两个特点。嗯，想想也确实是如此，我们好像做出了一个前人已有的产品嘛，没有特点就和没做一样嘛。为了答谢两位天使用户的干货反馈，我们决定赠与他们各3%的股权，并向大家发布了这个消息以激励更多的天使反馈。（嘿嘿，5%的最高配股奖励当然是不能轻易给出，大家都懂的，放在那里还要吸引更多的天使用户嘛~~~） 一正一反，一黑一白，两位天使的反馈拿到了，之后的关键就是我们该如何进行调整了。我们的CPO刘总双眉紧锁，抓破头皮（哈哈，这当然是我编的），然后做出了一个艰难的决策：调整产品方向，彻底放弃提前定餐服务，转向社交朋友圈约饭，然后推出餐付宝，最终以海量餐费支付作为盈利模式。这个决策的改变肯定不会是一帆风顺的，团队成员也提出反对的声音“这么大的调整我们还是在做最初定义的产品吗？”不过我们“英明”的刘CPO最终毅然决然的顶住了压力，坚定地推行了这个决定，而事后回想这其实就是整个游戏的关键转折点，让我们在后面的PK中占到了先机。我们当时选他做CPO真是选对人了。基于反馈对产品进行了调整，然后等待市场的再次检验，我们的路子完全是按照经典精益创业的剧本在走嘛，后面总该一番风顺了吧。可是狗血的剧情还在继续，在“黑暗森林”中的另外两名猎手也在瞄准着我们。。。。 接下来的第二个迭代我们这边并没有太多可说的了，就是在纸面原型上打造朋友圈约饭功能，试图通过这个功能先圈住用户。这里我来说说其他两个组的情况。“家乡菜” 团队本来的主打是“附近餐馆”，在第二轮迭代后又加入了订桌服务以及健康元素，很多好的想法，但却没有一个明确的主题定位。再说“来就吃” 团队，就是那个在第一轮中选择不发布的团队，他们是我们最大的冤家，因为他们居然和我们第一轮MVP的产品定位是一样的，都是主打“提前定餐服务”，在我们第二轮已经改变调整产品策略的时候，他们却还在一心想着怎样才能和我们在“提前定餐”这个产品细分上一决高下，处心积虑的推出了“免注册”服务试图通过提高用户留存率打败我们。在第二轮发布后，他们才知道自己扑了个空！当时，我都可以听到他们心碎了一地的声音，哈哈。这样虚虚实实的商战剧本竟被我们两个团队给真人秀了，但别急，后面还有更狗血的！ 第三个迭代中，其他两个团队大概已经感觉到了“微饭”的强劲势头，决定华华丽丽的进行高大上的“兼并重组”，试图合两家之力打败我们“微饭”。面对这个来势汹汹的杀招，我们微饭团队在评估了两位竞争对手的情况后，做出了“以一扛二”的生死决策，继续打造“餐付宝”这个最终杀手锏，以此在最终的角斗场上和对手进行决斗。反观另两个组的“华丽重组”则在后来演变成为了一场灾难，失败的公司重组成了下一个被真人秀的狗血剧本：两个产品没能有效的取长补短实现融合，重组后产品显得更加凌乱没有主题，而两个组的决策权也没有处理好，还是站在原组的立场各说各话。原本1+1>2的初衷却带来了1+1<1的结果，而作为这场“煎饼（兼并）”大戏的观众，我真正体验到躲在阴暗的角落里偷笑的感觉。。。（啊！西红柿飞来！另外两个组的同学表打我啊！） “他们在庆祝合并重组！！” 经历了三个跌宕起伏的MVP迭代后，这场最终的宿命对决在我们“微饭”和重组后的“家乡菜”之间展开了。我们组派上了CPO刘总一人去面对他们重组后的两个团队，面对对面黑压压一片、杀气腾腾、摩拳擦掌的气势，那时，我看着威风凛凛的刘总，不禁想起了“风萧萧兮。。。”不不不，绝对是“诸葛亮舌战群儒”的场景！这里卖个关子，不向大家交代我们两个产品对决的具体过程了（其实是写的太多，老婆喊去吃饭了），只能告诉大家两个产品的最终对决过程就如两位江湖大侠过招，你来我往，明争暗斗，枪林弹雨，刀光剑影，一不小心就会一败涂地，死无完肤，尸骨无存，人间蒸发。。。。等等，你这还是敏捷工作坊吗！这明明是地下黑暗铁笼擂台的节奏啊，太夸张了吧！嘿嘿，笔者认为当时的实际对决的紧张状况真的不亚于此哦！如果大家不信，想印证笔者的描述，有机会也可以来亲身参与一下Agile1001的O2O工作坊（赤裸裸的植入广告，太不敬业了。。。） 想来说到这里聪明的读者也已经猜到了故事的结尾，我们“微饭”最终赢得了游戏的胜利，席卷了另外两个组的集资（切。。。还用猜！你当大家是傻子吗！！开篇不就说了吗！）。欧也！把他们两个组的集资给朕拿来，弟兄们按照股份比例开始分赃，不对！分红！当我们拿到了他们两组的集资袋时，说实话，真是下了我们一跳，两组加起来整整960大洋，他们也真真的是蛮拼的啊！再看我们微饭组的集资，真是不要太开心了~我们组加上天使投资总共才160块！！！1：6，以小博大，完胜！我们组的队员是不是今天应该去买彩票！？ 这里停下来说说，为啥前面说我被选为CEO是很幸运的。其实是因为当时集资的时候，大家都让我这个CEO先放钱，我当时很囧的看着这帮队友们，心里飞速的想，黄喆啊，你这钱包包里的钱可都是好不容易才从老婆大人那里批下来的，平时卖体力做软件换血汗钱也不容易，你可要冷静，要冷静，想好了。。。最终我颤颤巍巍的从兜里费劲的掏出了50大洋放了进去，而我的这帮“亲密”队友思密达见我放了50进去，马上说“CEO就是豪爽！我们不能放的比CEO还多啊，Bula。。。Bula。。。”一个个比猴儿还快的都塞了10块钱进去，有一位看着最“忠厚老实”的同学可能是被我感召了，使劲咬了咬后槽牙，最后放了20。。。。而此时、此刻、此地，俺这个在三个半小时前被推到集资最前线的“CEO”，就成了全世界最幸运的宠儿！投入50，三个半小时，拿回股本，纯利284，净赚600%，干净利索！此刻我只能傲娇的说，哎呀！人生的第一桶金来的太快，伦家还没有准备好呢嘛~哈哈，当然，我的队友们，以及为我们投资并为我们提供极具战略价值反馈的天使投资人们也最终拿到了6倍的回报，大家都笑开了花儿（一群见钱眼开的家伙。。。敏捷圈子不是应该很高大上的吗？） “分赃有我！！哈哈” 好了，本来想简单写写就收笔的，一口气写了这么多，话痨毛病又犯了。最后，感谢一下立杰和伟忠两位老师为我们免费的提供了这次挣钱的机会。。。不对，是学习的机会！让我们在快乐的玩耍中学到了精益创业的很多很多。 再多说一个小细节，在最后我们拿到另外两组的集资袋看到960元的天文数字后，我们的第一反应是想把这笔巨款退还给他们，但当我们提出这个建议后，另外两组却无比爽快地拒绝了。。“有钱就是任性啊！”。当时我就想，虽然我们是赢钱的一组，但可能他们两组的同学们才是在这次工作坊中收获最多的人。和960块比起来，这些经历可能会成为他们创业路上的第一桶金。也许今天他们输了960块，但明天却会因此赚到960万，甚至也在美国上市圈他个960亿回来，所以我要赶紧代表“微饭”团队向他们献上最真挚的祝福！最重要的是，赚了钱别忘了我们啊~~~ 好了，真的就写到了这里了！不能再扯了，最后感谢敏捷之旅，感谢Agile1001，感谢立杰、伟忠、Bob、谢钊，感谢参与这次工作坊的所有同学，让我学到了这么多。祝愿Agile1001越办越好，我也会尽我的力量为Agile10001这个大家庭贡献更多的力量！ 记录者，黄喆，软件攻城狮，CSM，热爱敏捷、精益。目前工作于GE，从事软件过程改进、敏捷项目管理等工作。希望能在Agile1001这个大家庭中与大家交流、学习、共同成长。 筒子们，你们也想要开这样的工作坊吗？可以留下电话联系我们。。。 -——————————————————
2015/1/2
articleCard.readMore敏捷之旅2014北京站--意启工作坊《商业模式探索》
话题介绍- 商业模式探索工作坊： 当我们说敏捷，我们希望把事情做对；当我们说用户体验，我们希望产品能够得到用户的喜爱；而一个产品的成功，往往还需要第三个维度，它是否能够挣到钱？商业可行性对初创企业尤其重要。对商业模式的分析正是为了解决这类问题。这是一个风靡的名词，商业模式画布，帮团队在产品诞生初期可视化设计商业模式，再根据市场变化去调整。商业模式是否仅仅只是商业模式画布？不！真实的初始化过程，饱含假设，纠结，岔路，抉择。 意启部落小伙伴们来了，让我们来一起体验一个商业模式如何诞生。 工作坊中会涵盖： - 产品网络图分析 - 画布分析 - 价值主张探索 - 画布迭代 - 商业模式假设验证 意启工作坊介绍： 如果您还在用老的方式在创业、创新，寄希望有一个“好”点子砸到你的头上，然后一举成功，那你还没有开始就已经Out了。意启致力于帮助传统行业的创业团队利用颠覆性方法和流程加速孵化。目前意启正在帮助甜甜圈和会把奶牛帮两个传统行业的初创企业加速成长。同时，意启还学到的和体验到的总结并推出系列课程。意启目前关注的颠覆性方法和流程包括：Growth Hacking、病毒性传播、傆型(Pretotyping)、增长引擎、精益创业、引导技术、设计思维(Design Thinking)等。 12月20日，我们不见不散：报名地址
2014/12/16
articleCard.readMore敏捷之旅2014北京站--敏捷一千零一夜《敏捷实战之O2O精益创业》
敏捷实战之O2O精益创业 进入2014年，移动互联网开始不断重构我们的生活，最典型的例证莫过于O2O的全面开花，从以“美团、大众点评、京东快点”为代表的团购、点评等服务，再到以“嘀嘀打车”为代表的“我要我有模式”的打车、家政、美甲、外卖等服务，无不对传统行业开始新一轮颠覆。在这个以速度见称、以用户体验为重的时代，敏捷又该如何切入？如何调整？如何做到低成本的快速交付?如果你想挑战一下自己，请参加我们这个工坊。 这是一个纯玩体验工坊，因为我们一直主张在实战中获取经验值，所以你会跟你的新成员一起做计划、掷筛子、制作图表、做纸面原型、拜访客户、情景话剧、现场演示。。。。。玩得High与不High,请尽情发挥想象力吧！场地原因，我们只招募4个创业小组，每个小组只有8人，需要ScrumMaster、PO各1人，Scrum Team由分析、开发、测试角色各2人组成跨职能团队。其他再多的人可以充当围观呐喊者，当然也可以客串各个团队的客户(其实，从别人的成功失败中，获取经验也很重要的)。四个小组会共同面对一个O2O命题作文(暂时保密)，需要以敏捷、精益的方式展开工作，经历三个Sprint快跑。在这个PK过程中，每个团队需要在一个下午的时间内亲手做出来产品原型，供客户检验，得到现场呼声最高的团队胜出。当然，你们需要跨过我们提前设置好的各个障碍。 兴奋？紧张？担心？焦虑？没有关系，本次工坊由Agile1001富有经验的经典F4组合倾情奉献，并提供贴身指导。 -——————————————————————————- ² 关于F4团队 我们专注于各种案例故事分享，重点覆盖敏捷开发、精益创业、产品创新、组织变革等话题，每月至少一次公开课。 ² 敏捷一千零一夜Team介绍： 王立杰， 《敏捷无敌》作者 ，《敏捷开发一千零一夜》主编，多年研发管理与敏捷实施经验，专注于精益创业与产品创新、敏捷组织转型、研发效率提升。曾为百度、Nokia、VMWare、爱立信、朗讯、E人E本等多家公司做过各种敏捷培训和咨询；曾经在 “Scrum Gathering、 AgileChina、 Agiletour、51CTO、TiD”等大会做过多次演讲，荣膺2014 TiD大会10大最受欢迎讲师。 姜信宝， 喜欢新鲜事物，喜欢读书，喜欢分享，愿意和大家共同进步。 Agile1001公开课联合发起人之一。（https://agile1001.org) 我的博客：https://bobjiang.com 《Essential Scrum》译者（原作者：Kenneth S. Rubin） E-MAIL: jiangxb@gmail.com CSP,CSM,PMP 热衷和推广敏捷，是中国敏捷社区的主要推动者之一。 杜伟忠， 多年软件研发和管理经验，主要专注于精益与敏捷落地实践。曾多次在QCon、TOP100、敏捷大会上做分享。 谢 钊， 十年软件实施、项目管理、产品设计分析等方面工作经验，目前主要专注于敏捷、精益、产品规划、企业知识管理等方面的学习、实践和探索。 工作经历：服务过的公司包括海辉集团（现文思海辉）、软通动力，目前在职于京东商城。 参与并组织过的敏捷相关活动： 2013年敏捷之旅（北京）大会； 2014年的Scrum Gathering大会； 2013年度敏捷厦门群英会； 业余爱好：绘画（书法），每天在微信圈分享一副习作（凡关注者均有可能获得习作一副）。 积极、主动、乐观；学习、交流、提升、分享！ 有钱就是这么任性，报名地址：请点我
2014/12/16
articleCard.readMore敏捷之旅2014北京站-与敏捷思奔之旅
自从2010年开始，敏捷之旅北京站已经连续成功地举办了四届。2014年12月20日将迎来敏捷之旅北京站第五届，此次的主体是 与敏捷思奔，旨在将本地的同行聚集在一起，分享知识，交流经验，将有众多业内知名敏捷实践者分享多年实战经验，更有真枪实弹的敏捷代码切磋互练，欢迎敏捷爱好者踊跃参加，与我们一起探讨软件开发的敏捷思奔之旅。 活动时间：2014年12月20日 09:00-18:00（周六） 活动地点：北京市海淀区上地西路6号联想研究院 活动费用：需支付门票，组织者提供与会人员饮用水及午餐（非盈利活动，门票收入用于讲师差旅以及活动组织费用） 购票须知： 为了更好的参会效果，此次敏捷之旅北京站接受报名300人，现场支付票价100 RMB 普通票价80元RMB，早鸟票价已售罄 5人以上团体购票，请联系 姜信宝 jiangxb@gmail.com 13910939018 支付方式： 支付宝转账：13810098755（jaylian@yeah.net） 廉雨 微信红包：加 13810098755（jetlian12）廉雨 海丁网线上支付 https://t.cn/R7sh7gh 支付说明： 转账同时留下姓名、电话及邮箱 此账号是唯一通过转账报名方式 联系赞助：agiletourbeijing@gmail.com 活动奖品 ShineScrum提供的价值7000元CSM认证培训名额1个 银河快车提供的价值450元南山滑雪场全天滑雪情侣电子票3对 精美专业图书100+ *日程安排* 上午场 时间 主题 会场 9:00 9:30 签到 前台 9:30 10:30 《Scrum想说爱你不容易》 姜信宝 主会场 10:40 11:40 《产品开发的敏捷原则和方法》 周金根 主会场 11:40 13:00 午餐 下午场 时间 分会场1 （商业画布） 分会场2 （敏捷实战） 分会场3 分会场4 13:00 14:00
2014/12/15
articleCard.readMore敏捷之旅2014北京组织者详细介绍
Agile Tour（以下称为敏捷之旅）是一个国际非盈利性组织，于2008年成立，总部位于法国。其目的是提供一个高效有趣的敏捷开发学习途径，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。它通过一系列的活动，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。 非盈利活动的背后离不开一大群“最可爱的人”，即我们每年活动的组织者们。正是有了他们牺牲自己宝贵的休息时间和与家人团聚的时间，才能使敏捷在北京传播开来。让我们来认识下2014年北京站组织者： 姓名： 张峰 部门岗位： 京东-云平台-高级经理 邮箱：zhangfeng@jd.com 主要工作经历：2005年毕业后从事冶金行业自动化工控程序设计，后在国产数据库公司人大金仓工作，2009年进入电商行业，加入B2B & B2C 综合电商千寻网，2010年加入京东，见证了京东POP平台从无到有的过程，参与过POP商品、类目、订单等多个系统的建设，并带领团队完成京东机票系统第一版的设计和上线，2011年负责京东开放服务（JOS），现负责京东服务市场，京东服务定制（众包模式）等业务 姓名： 张明 公司： 联动优势 邮箱：Thomas0927@163.com 个人简介： 认证Scrum专家（CSM）2006年毕业后在方正从事银行系统程序设计研发，而后参与过民航系统、通信系统的多个领域的设计研发工作，2011年进加入联动优势电商公司，负责第三方支付平台搭建，参与过账户核心系统改造、风控防钓鱼、预授权支付、快捷支付、付款平台等多个系统的建设，并带领团队完成基础支付平台、付款平台等系统设计研发和上线，负责电商公司基础支付组，参与支付平台系统优化改造。目前在项目中正推行敏捷，希望能和大家进一步交流学习。同时，也是另一个NGO组织（960灾难逃生救助公益组织）的参与者和发起人之一 姜信宝 （Bob Jiang） 敏捷教练，旨在帮助企业改进工作流程以取得更好的商业价值。 作为一名认证的Scrum专家（CSP，CSM），他曾在爱立信为公司提供敏捷转型的支持，为北京移动提供过敏捷辅导，现在他正在京东商城进行精益敏捷的转型。在此期间，他曾担任过ScrumMaster、团队成员和项目经理等不同角色，深谙敏捷转型的艰辛与不易。另外他还是《Scrum精髓》一书的译者。 Bob是国内敏捷社区的主要推动者，从2011年起他组织并参与了敏捷之旅、ScrumGathering China 、敏捷中国、QCon等大会。另外他还是Agile1001公开课（https://agile1001.org）的联合发起人，微信公众号是Agile1001。他的博客是https://bobjiang.com 廉雨 邮箱：bjlianyu@hotmail.com 个人介绍： 一名开发人员，敏捷爱好者，CSM。 专注于敏捷开发，敏捷个人，喜欢跑步、旅游、阅读等。 一直在传统企业为政府等做业务系统。 13年开始接触敏捷，并在团队中推广敏捷。在敏捷组织中收获很多，向更多敏捷前辈学习。 熊志男 我是一名测试老人，敏捷新人。传统的测试工程师正在被边缘化，通过学习和实践敏捷，我对于测试的理解也逐渐从“和开发对着干”发展到“无意与开发为敌”，再到今天的“打入开发内部”，真正融入团队中，抛开以往头衔和职位对于自己的限制，为团队中每个成员服务，也为自己服务。 刘芸 微信号：ly15201392806 邮箱：liuyun@phei.com.cn 电子工业出版社博文视点策划编辑，专注于IT专业技术图书的策划出版服务。IT相关技术爱好者，曾编辑出版过《京东技术解密》、《Swift语言快速入门》、《敏捷方法论》等多领域图书。 谢钊 积极、主动、乐观；学习、交流、提升、分享 十年软件实施、项目管理、产品设计分析等方面工作经验，目前主要专注于敏捷、精益、产品规划、企业知识管理等方面的学习、实践和探索。 l 工作经历：服务过的公司包括海辉集团（现文思海辉）、软通动力，目前在职于京东商城。 l 参与并组织过的敏捷相关活动： Ø 2013年敏捷之旅（北京）大会； Ø 2014年的Scrum Gathering大会； Ø 2013年度敏捷厦门群英会； l 业余爱好： Ø 绘画（书法），每天在微信圈分享一副习作。 Mail：zxie2008@gmail.com；微信：iamxiezha 姓名：喻泽高（安静的发狂者） 公司：联想研究院 邮箱：dennis.yu@live.cn 个人简介： 高级软件工程师，多年VOIP从业经验，丰富的移动互联网即时通信应用开发经验，专注移动互联网音视频通信领域，目前就职于联想北京研究院视频通信技术研究室，负责联想明星产品“友约”的后台架构设计和实现。认证Scrum专家（CSM），推崇敏捷方法和自组织团队，并在团队中推广，颇有收获，非常期待能与大家交流学习。 王一男 北京航空航天大学软件工程与管理硕士，现广联达软件股份有限公司PMO经理、公司研发管理信息化及敏捷研发管理培训讲师、公司研发管理信息化项目经理、敏捷教练 拥有丰富软件敏捷研发管理实战经验，先后在两家上市企业成功实施基于信息化工具的敏捷项目管理，并成功实现了基于信息化数据度量的敏捷团队持续过程改进。 在2014年TID（中国质量竞争力）大会上被评为最受欢迎讲师，演讲题目：《敏捷项目度量》、《Atlassian工具集在敏捷项目管理的应用实践》 姓名：Melody LIU（刘玉青）
2014/12/15
articleCard.readMore敏捷之旅北京
1.什么是敏捷之旅（Agile Tour）？ Agile Tour（以下称为敏捷之旅）是一个国际非盈利性组织，于2008年成立，总部位于法国。其目的是提供一个高效有趣的敏捷开发学习途径，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。它通过一系列的活动，在全球的范围内 极大推广敏捷 希望通过一系列活动，在每一个参与城市都对敏捷思想引发足够的关注，并形成一个敏捷开发的社区。 分享敏捷的愿景 敏捷在持续演进，希望在打开新的视点的同时也把我们对敏捷的理解和观点分享给整个敏捷社团 联合 在保持敏捷文化和自治的同时，在世界各个地区提倡和提升敏捷的领导力 支持 帮助同行，朋友和本地商业机构转向敏捷方法 2. 敏捷之旅—足迹 自2008成立以来，每年的10月至12月，敏捷之旅都会在全球范围内举行活动，让更多的人了解敏捷。而每年参加的城市和人数也迅速的增长，已成为全球规模最大的敏捷大会。而截止目前已有84个城市申办敏捷之旅活动。 下面是申办城市的列表： 3. 敏捷之旅—在中国 敏捷之旅在中国行始于2009年成都，最早把敏捷之旅引入中国的是成都的敏捷先驱们，敏捷之旅成都-2009的讲师有Stéphane Lécuyer、Vernon Stinebaker、顾全、Julien Mazloum、Brenda Bao、徐毅。而从2010年开始，国内敏捷社区的一批先行者，包括知名的敏捷培训师和教练，开始在全国范围内组织敏捷之旅系列活动，以让更多的城市和更多的朋友借此平台，了解敏捷，结交朋友，交流互动，从而形成一个全国范围内的社区平台。 从2009年至今，敏捷之旅在中国申办过的城市已经扩展到了成都、北京、上海、杭州、深圳、广州、西安、青岛、大连、福州、天津、厦门、广州、太原、南京、苏州、大连、香港、长沙、郑州二十个城市。 参加过敏捷之旅中国的众多国外知名专家包括（不限于）： · Jean Tabaka 拥有30年软件开发行业经验，著有敏捷软件开发系列丛书《CollaborationExplained: Facilitation Skills for Software Project Leaders 》。 · James Grenning 敏捷宣言创始人之一, Renaissance Software Consulting 公司创始人，全球知名讲师，过程教练及咨询师。 · Patrice Petit 全球知名敏捷教练，咨询师，敏捷之旅（Agile Tour）的创始人 · David Hussman 2009年Gordon Pask大奖的获得者，参与了很多书的编写工作，具体有：《AgileSoftware Development in the Large, Managing Agile Project》和《Agile Software Development with Distributed Teams》。在全球各地培训和培养敏捷教练，有超过十年的敏捷培训经验. · Gojko Adzic 全球知名敏捷专家和教练，敏捷畅销书《Bridging the Communication Gap》 和《Specificationby Example》的作者。
2014/12/15
articleCard.readMore谁是最可爱的人 - 敏捷之旅2014北京的组织者们
2014年12月20日，在联想北京总部，来一场“与敏捷的思奔之旅”？ 那么我们来看看这趟旅程都有什么奇妙之处： 我梦想创业，可是不知道如何找到好的商业模式？ 意启部落小伙伴们带我们一起体验一个商业模式如何诞生。 O2O很火，你知道吗？ Agile1001的F4团队将以精益创业的思想带我们进行O2O项目实战。 想与敏捷大牛面对面交流吗？ 姜信宝、申健、张伦、周金根、寇晓东、王立杰、王栋、施勤文、刘新… 知道互联网企业中的敏捷先锋是如何实践的吗？ 来自于京东商城的王栋和汽车之家的冯林与大家分享敏捷布道之路。 总有些意料之外的小惊喜 图书奖品、早鸟优惠价、便携记事本… 谁是幕后英雄，敏捷之旅2014-北京的组织者： 报名请戳： https://www.headin.cn/Themes/Activity/Details/?activityId=5466c604c3378ff3a4de7665 关于敏捷之旅： https://agiletour.cn/
2014/12/15
articleCard.readMore京读会第二次分享记录
分享人：申立君 分享书籍：《安德的游戏》
2014/11/26
articleCard.readMoreScrum角色-Scrum入门基础系列
Scrum中定义有三个角色 产品负责人 ScrumMaster 开发团队 另外还会提到两个常见角色（经理和项目经理）在Scrum当中的职责。 产品负责人 职责 产品负责人最大的职责是为产品的投入产出比（ROI）负责，即最大化团队的投入产出比。在Scrum当中，由于Sprint是时间盒（即时间是固定的），且成本（软件开发中人力成本是最大的成本，其他忽略不计）也是固定的，那么最大化投入产出比就是如何做出最有价值的产品增量。 创建产品愿景 创建与维护产品Backlog（插播一句，Jeff Patton同学很不喜欢Backlog这个词，听起来产品还没有开始开发就落后了，如果谁有更好的词我们可以一起交流） 主持产品Backlog优化会（增加、删除、修改或细化用户故事，并根据需要进行排序） 协调干系人与开发团队之间的沟通 参加团队的Scrum会议 在Sprint计划会上和团队一起决定当前Sprint的开发内容 接受或拒绝团队的产品增量 决定何时发布 所需技能 根据上述的职责，作为产品负责人需要以下技能： 业务能力 - 产品负责人首先要对产品以及所在行业有较深的认识和理解。这样才能根据业务价值来对不同的需求进行排序，或者对产品的整体方向有感觉。 技术能力 - 虽然产品负责人不必是技术专家（SME），但懂一些技术对于需求排序、拆分、优化是有很大帮助的，特别是在参加Sprint计划会的时候，可以很容易的理解开发团队。 决策力 - 产品负责人接受或拒绝产品增量，那么对于产品负责人他就要有授权，可以决策哪些是可以接受，哪些要拒绝。以及决定什么时候发布，什么特性优先级高等等重要事项。 沟通协调能力 - 产品负责人需要有很强的沟通协调能力，因为他是干系人与团队之间的润滑剂。 谁来担任 简单的回答，可以完成上述职责并拥有上述技能的人都可以来担任产品负责人。较常见的是产品经理担任。我见过的还有项目经理、架构师等不同岗位转型为产品负责人的。 ScrumMaster 职责 Scrum权威 - ScrumMaster是团队中最熟悉和了解Scrum框架的，并可以根据实际情况对团队进行指导。 辅导团队和产品负责人 - 如果产品负责人或团队不知道该怎么办，ScrumMaster需要提供相应的辅导、培训或支持。 保护团队 - 在一个Sprint中，ScrumMaster要保护团队不受打扰，可以专注于Sprint目标和承诺。 移除障碍 - ScrumMaster要善于发现障碍，并可以帮助团队移除障碍，包含但不限于个人障碍，团队障碍以及组织级的障碍。 变革大师 - ScrumMaster不仅要在团队内实行Scrum，还要能够影响并促进组织或整个公司内的变革。 所需技能 热情 - 首先ScrumMaster需要是一个有热情（Passion）的人。热爱并喜欢自己的工作，充满激情，并且可以感染周围的人。 主动学习 - 学习是永无止境的，作为ScrumMaster，需要主动的学习，补充自己的短板，刻意的练习，成为真正的master（大师）。 善于提问 - ScrumMaster不一定是所有问题（尤其是技术上的）的大师，但他一定要能善于启发团队思考并行动。这往往是通过提问来实现的。好的问题可以让团队清晰的认识到自己。 耐心 - 对于变革要有耐心，可以容忍团队犯错误。让团队在错误中学习并成长。 协作沟通 - ScrumMaster需要和团队沟通，了解个人障碍和团队障碍。也需要和团队外的干系人沟通，来排除障碍或了解他们的期望。总体说，ScrumMaster需要较强的沟通能力（和产品负责人类似）。 公开透明 - Scrum的三大支柱之一就是透明。因此作为ScrumMaster也需要公开透明，不仅仅是团队的进展要透明，所有的沟通交流也需要是透明的。只有信息透明，才能产生信任与尊重。详情可以参考《克服团队协作的五种障碍》 谁来担任 常常问道的一个问题是，ScrumMaster是全职工作吗，可以兼职吗？对于一个新组建的团队，我强烈建议全职的ScrumMaster。因为有很多的事情需要ScrumMaster来做，参考上面的职责。如果是成熟的团队，ScrumMaster可以兼职，但不建议既做ScrumMaster又做开发工作；但可以同时是两个团队的ScrumMaster，因为工作类型是相似的。
2014/11/12
articleCard.readMore京读会第一次分享记录
京（精）读会，京东人自己的读书会，精品阅读俱乐部。 感受读书乐趣，体会阅读收获，分享朋友感受。 在这里你可以找到一起读书的小伙伴，也可以听到很多有趣的书评。欢迎爱读书的小伙伴来参加我们的活动。 Bob Jiang 几种书不读– 当下热卖的书不读，人物传记不读（尤其非本人写的），心灵鸡汤类不读 笔记方法– 读书的时候，有重点要点内容，记录在书前面并标注页数 读书时，重点关注重点段落（如标题，黑体等），以及段落的首尾句子。 读英文书时，尽可能不查字典，靠上下文猜。 推荐的三本书 《做不可替代的人》 《The Principles of product development flow》 《creative confidence》 程文宇 不读 - 厚的，读不懂的 喜欢读 - 历史、快餐类、科普类，工作有用的 先看目录，先读有兴趣的章节 推荐的三本书 《金字塔原理》 《曾国藩》 《专业主义》 申立君 1、选书：喜欢同学、老师、同事等亲近的人推荐，会更贴近自己的实际情况，也可以方便讨论分享； 2、有目的的看书，抱着问题去看，更容易看得进去，收获也更多； 3、速度更快：首次看书过程比较粗略，留下记号，标注难点、精彩的地方，再根据书本值得看的程度，决定看不看第二次，第二次阅读的重点是什么； 4、便利贴标记：随手贴留记号，方便回顾，也不伤害书本；利用不同的颜色代表不同的含义；摘录要点，随手贴在家里任何地方； 5、读书笔记：用思维导图记录书的框架和要点；写书评；特别好的书，做成PPT、信息图，与大家共享； 6、向别人推荐书目：很好的交流过程，也可以督促自己多读书； 7、记录读完的每本书写在卡片上，记下日期，定期回顾数量和心得，非常有成就感，激励自己； 8、文学作品的阅读： 阅读有争议的文学作品，可以先去网上搜搜大家的观点和争议，自己再去品读会更有效率； 读小说，快速看整段的内容，抓动词、转折等这些关键点，可以更快的理解小说内容； 读小说，先查查作者的生平背景，可以更好的理解小说意义； 读之前，可以看一下同名小说改编的电影； 推荐的三本书 《百年孤独》 《组织行为学》 王颖 我的读书方法： 1.制定年度读书目标； 例如，一年读30本。年底总结一下，对下一年的目标进行调整。（可参考各国家人均读书量，无限动力） 2.书非借不能读也； 除了百年畅销和工具用书，建议不要买书。跟朋友、同事借，或者直接去书店站着看，这样看书最有效率。 3.不要纠结 一本书，其中某个段落不是很理解，反复两天都卡在这几页。那么不要纠结，直接跳过。整体看完了自然就理解了，或者不影响整本书的指导意义。 4.带着问题读书 每本书都是作者的经验精华，但未必每个人在读的过程中都能全面吸收。带着问题读书，生活/工作中的问题解决了，就是活的读书笔记。 推荐的三本书 《明朝那些事儿》 慕容雪村 - 梦境 刘玮玮 读哪些书： 以互联网、电商、科技、信息类为主。 读书方法： 一般是按需读书。先看目录，重点章节细看，了解的、信息量低的章节粗看。 以经典书为主，但时下的行业联系紧密的新书也会买来看。 会在书上写写画画，也会用专门的本子记录要点，并在本子上写下思考的灵感。好书会写书评。也曾期望一书一评。几本相关的书读下来，会写文章投稿。
2014/11/5
articleCard.readMoreScrum框架-Scrum入门基础系列
Scrum入门基础系列之Scrum框架 读过几本Scrum书的人，想必对于Scrum框架都可以如数家珍，如Scrum的3个角色，5个会议，3个工件。在展开这些内容之前，我想先介绍一下Scrum的价值观以及敏捷宣言。 敏捷宣言[1] 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： 个体与互动 胜于 流程与工具 可工作的软件 胜于 详尽的文档 客户协作 胜于 合同谈判 响应变化 胜于 遵循计划 也就是说，尽管右项有其价值，我们更看重左项。 Scrum价值观[2] 专注：一段时间内只专注于少数几件事情。Stop Starting, Start Finishing。团队的能力（精力）是有限的，在有限能力和有限时间范围内，专注于最有价值的事情，以取得更好的成果。 勇气：我们需要勇气去迎接各种挑战。 公开：在团队中公开进展（Progress），即可视化、透明，这样可以很容易的暴露出风险问题和障碍。并且透明也是尊重、信任的基础。 承诺：自组织团队开始的时候做出承诺，并在迭代期间尽全力完成履行承诺。 尊重：团队是坐在一起的，长期稳定的，这有助于加深彼此的尊重和了解。 Scrum框架 Scrum框架是不是银弹，也不是灵丹妙药。实行Scrum不需要团队成员都是精英。因为Scrum只是快速的把问题暴露出来，以至于我们无法忽视和忍受它。Scrum框架是一个团队的流程框架，由自组织的团队进行改进完善。该框架主要包含角色，会议和工件三大部分。 角色 产品负责人（Product Owner） - Scrum中对产品负有全部责任的唯一人。产品负责人需要创建和维护产品Backlog，并需要参加必须的Scrum会议，如Sprint计划会、Sprint评审会等。详情可以期待下一篇博文（Scrum角色）。 ScrumMaster - 这个角色是Scrum框架提出的新角色。他需要对整个Scrum框架非常熟悉，还需要是一个变革大师。在Scrum中，ScrumMaster没有授权，而还需要完成很多的工作，如移除风险等。 开发团队 - 开发团队指的是跨职能的自组织团队。开发团队中可能包含开发人员、测试人员、用户体验工程师、数据库专家等。开发团队负责完成端到端的工作，从而在Sprint结束的时候可以完成产品增量。 会议 Sprint计划会 - Sprint计划会主要分为2部分：做什么和如何做。Scrum团队一起决定他们要做什么，以及如何构建、测试承诺的工作。在计划会议过程中，产品负责人的重要职责之一是解释澄清模糊的需求。最后的产出为Sprint目标和Sprint Backlog。详情敬请期待后续博文。 每日例会（Daily Scrum） - 每天的15分钟站立会议。Scrum团队一起回答三个问题：从上一次例会到现在我完成了什么（重点在于是否完成承诺，以及暴露风险）？从现在到下一次例会我计划完成什么（重点在于承诺）？有什么风险或障碍（尽早暴露问题风险）？ Sprint评审会（Review） - 在Sprint评审会上，产品负责人接受或拒绝团队完成的用户故事。（注：产品负责人应该在平时的工作中进行评审，而不是只在评审会上进行这些工作）这是一个非正式的会议，准备时间不要超过1小时。（注：但必备的准备工作还是需要的） Sprint回顾会（Retrospective） - Scrum团队一起检视和调整他们的工作方法，以达到成熟高效的自组织团队。 产品Backlog梳理会（Product Backlog Refinement） - 由产品负责人组织协调干系人或团队一起进行产品Backlog梳理，包含但不限于新增需求，删除需求，修改需求，拆分需求，改变需求顺序等等。 工件 产品Backlog - Scrum中需求存放的清单，常见的格式为用户故事，也可以包含其他类型的内容，如缺陷、用例、史诗故事等。 Sprint Backlog - 由Sprint中承诺的故事和相应的任务组成。在Sprint过程中，团队每天都会更新Sprint Backlog，在每日例会上讨论并同步有关Sprint Backlog的信息。
2014/10/30
articleCard.readMore敏捷会议魔方
作为ScrumMaster或会议主持人，你有没有碰到过如下问题： 会议开着开着跑偏了 会议超时了 会议没有结果 不知道该干什么了 敏捷会议的神器来了 - 敏捷会议魔方。使用这个魔方，可以为你提供会议何时开，开多久，会议的目标，会议的检查清单，成果以及会议中用到的工具等等，详情可以参考上述的示例。 其中的会议包括： Sprint计划会 每日例会 Sprint评审会 Sprint回顾会 计划发布会 产品Backlog梳理会 怎么用这个魔方呢？ 从下面的链接下载文件 打印出来 用剪刀沿着虚线进行裁剪 用胶水把6个面粘起来。 agile-meetings-cube-CN_PDF 原文链接： https://blog.crisp.se/2014/10/16/peterantman/the-agile-meetings-cube 感谢Crispe公司的Peter Antman
2014/10/30
articleCard.readMoreScrum起源-Scrum历史-Scrum入门基础系列
Scrum入门基础系列之Scrum起源 说起Scrum就不得不提Scrum之父 - Jeff Sutherland和Ken Schwaber，Jeff在1993年结合他的工作实践创建了Scrum框架，1995年Ken在OOPSLA会议上第一次发表Scrum的论文。此后Scrum之父的两位分别撰写过多篇文章，并联合发布了《Scrum Guide》（Scrum指南）。有关具体的Scrum起源可以参考我之前的一篇博文 - Scrum起源。 说到Scrum的起源，让我们再来看看Scrum的3大支柱：Inspect Adapt Transparent。 其中transparent（即透明性）为基础。离开了透明性（公开）的话，团队成员之间就没有信任和尊重的基础，也很容易发生更多的问题。 另外两个支柱经常一起提到，Inspect and Adapt，即检视与调整。检视与调整组成一个循环。检视，就是查看当前的可交付产品、流程等一切可见的内容；然后根据检视的结果进行反思，下一步如何调整工作计划、流程等等。说到这里，有没有觉得很耳熟呢？检视与调整，PDCA（Plan Do Check Act）环。计划、执行、检查、处理。是的，这就是著名的戴明环，是美国的质量大师在1950年提出的质量改进循环。 然而，PDCA环是戴明原创的吗？让我们往前推20年，看看1930年另一位美国的质量大师沃特 休哈特提出一个PDS（Plan Do See）的概念，和PDCA是不是很相似呢？是的，没错。戴明就是从休哈特的PDS中进一步发扬光大而提出的PDCA环的。 再一次发散一下，这让我想起我读过的一本书《偷师学艺》，书中开篇第一句就是“没有什么是原创的”。大师就是读很多很多书，然后能够吸收消化这些内容，把它们变成自己的再写出来。 怎么样，你有什么感想呢？ Scrum入门基础系列： Scrum入门基础系列之Scrum起源 Scrum入门基础系列之Scrum框架 Scrum入门基础系列之Scrum角色 Scrum入门基础系列之Scrum会议 Scrum入门基础系列之Scrum工件 Scrum入门基础系列之Scrum需求梳理 Scrum入门基础系列之Scrum估算
2014/10/23
articleCard.readMore《Scrum精髓》作者Ken Rubin访谈录——2014年ScrumGathering中国大会主题演讲者
原文链接：https://www.infoq.com/cn/news/2014/10/scrum-interview-ken-rubin Bob: 多数Scrum书籍是写给开发团队看的。为什么经理或高层也应该看《Scrum精髓》呢？这可是500页的一本书啊！ Ken: 这个问题分为两部分。为什么经理或高管应该熟悉Scrum？为什么尤其是管理层应该读这本书？ 第一部分，为了敏捷的长期成功，组织必须要遵循敏捷原则。经理和高管是遵循敏捷原则的基础。如果高管们不了解敏捷的核心原则，那就很可能他们制定决策和采取行动都是违背了成功采用敏捷交付商业价值的。换句话说，组织内整条价值链遵循敏捷原则对于实现敏捷真正的价值，是非常重要的。 仅仅在开发团队层面相信敏捷和Scrum是目光短浅的。我的经验是Scrum成功的公司，经理和高管都开始拥抱敏捷原则。因此我强烈认为经理和高管必须熟悉敏捷原则和Scrum实践。 第二部分，为什么经理和高管应该读这本书呢？好吧，有个小秘密，这本书原本是专门为经理和高管写的。原来的书名打算叫做“Scrum：管理者指南。”该书旨在告诉经理和高管，通过经济的方法采用Scrum和敏捷，本书和许多其他以开发者或技术为中心的敏捷书籍是有所区别的。 开始写作时，我想写一本易读易懂、图文并茂并以经济为基础的Scrum书籍，不仅经理和高管可以受益，Scrum团队的所有成员也可以受益，这个目标愈发清晰。在写作和从读者收到反馈时，我会大概查看与调整本书的中心思想。 我很愿意做出这种改变，因为我从不相信技术人员只受到技术内容影响，并只想阅读技术书籍。以我的经验，最好的技术人员作出经济有效的决策来指导他们做出技术权衡，并且因此体会到相同风格的讨论可以得到经理和高管的认同。另外，对于技术和业务人员通用的方法使它们共享相同的Scrum知识，因此大家在讨论Scrum及其影响时使用相同的词汇和框架。 本书有500页，从前到后摘录关键内容时，实际只有不到400页。而且，书中还有208副图片——这是我用来呼吁经理和高管的图文并茂方式的延续。本书中至少每隔一页就有一张非常棒的图片，结果就可以快速阅读且很有吸引力。 Bob: 如果从本书中总结一件事情，那会是什么？ Ken: 成功的Scrum来源于价值链横向和纵向都以经济合理的方式采用核心敏捷原则。因此，不论是开发团队成员还是高管采用核心Scrum实践，我们应该采取相似的方式。 Bob: 为什么又写一本Scrum书籍？ Ken: 很好的问题。有以下几个原因。 首先，多数流行的Scrum书籍慢慢过时了。在有些重要的方面，他们实在不能代表当下的实践状态。 其次，不能只是有一本书不仅描述核心的Scrum框架，还有采用Scrum的大多数通用方法。当要回答下面问题时我发现不得不推荐好几本书籍，“开始Scrum你会建议我们读哪本书。” 再次，我发现大多数人的学习是通过结合卓越的视觉表现与宏大叙事以改善的。实际上真没有一本Scrum书籍能提供一套出色的视觉表现，以帮助人们掌握敏捷核心概念。 关于作者 Kenny Rubin 是Innolution公司的管理负责人，该公司是一个敏捷培训公司，主要是帮助组织以一种有效和经济合理的方式来开发产品。作为一名认证的敏捷教练，Rubin已经在敏捷和Scrum、Smalltalk开发、管理面向对象的项目和转型管理方面训练了超过18,000人。他曾在200家公司进行过培训，涵盖的范围从创业公司到财富榜前十的公司。 Rubin是全球Scrum联盟的首席常务董事，该联盟是一个非营利性的组织，主要从事于进行成功运用Scrum的研究。除了创作《Essential Scrum：最流行敏捷过程的实用指南》这本书，他还是1995年出版的《Succeeding with Objects：项目管理的决策框架》的合著者。想了解更多他的背景请登录：https://www.innolution.com，你也可以在该网站上关注他的博客。Twitter的粉丝关注他请@krubinagile。 感谢侯伯薇对本文的审校和杨赛对本文的策划。 购买《Scrum精髓》
2014/10/20
articleCard.readMore认可（recognition） - 在敏捷软件开发中的作用
在一次和滕振宇、Michael James的cotrain过程中，讲到开发团队的职责时，碰到一个很有趣的讨论结果。当时讨论的问题是： 日常工作中，什么时候你的心情会很好？ 最后有3组同学都提到了“认可（recognition）”这个词。但更有趣的是，虽然都说认可，不过认可的程度是不一样的。下面我就认可在敏捷软件开发中的作用展开谈一下。 自我认可 团队的认可 管理层的认可 客户的认可 1. 自我认可。 你有没有做完一件事情后发现，哇，时间过的这么快！好有成就感啊，又搞定了一个问题！一般这样的情景发生在什么样的事情上呢，或者什么时间呢？这个现象叫做Flow（心流）。 还记得在Dan Pink的《驱动力》（参见我的读书笔记）一书中，提到驱动力3.0的概念（1.0和2.0大家去买一本书自行脑补哈）。在驱动力3.0中（即内在驱动），Dan提到3个关键因素：自主（autonomy），专精（mastery）和目的（purpose）。要达到Flow，上述的3个因素是很关键的。首先是自主，人们可以决定自己做什么，怎么做，什么时候做，在哪儿做。其次是专精，每个人都有一颗专精的心，什么事情都想精益求精，做的更好。刻意的练习，是一条通往专精的康庄大道。最后是目的，不论做什么事情要有明确的目的，可以参考SMART原则。 2. 团队的认可 在Scrum中提倡的是团队绩效，团队的结果。但不代表Scrum就不鼓励个人，最常用的方法是激励卡或感谢卡（为什么采用这种方式呢？给大家留个问题）。Scrum中团队被认可是很关键的，怎么实现呢？进展（progress）很关键，也就是说通过Sprint review来评审潜在可交付的产品增量。每个Sprint都会产出一些结果，因此管理层或客户能感受到实际的内容，也会基于这些内容提供一些反馈。 3. 管理层的认可 管理层的认可，这个问题稍微复杂一点。作为管理层，常常关注在KPI，度量结果。度量本身是一个非常复杂且庞大的问题。根据度量的目的和意义，可以把度量划分为两类：A.如果度量对于团队和个人具有正向激励作用，这就是一个好的度量。 B.如果度量对于团队或个人具有负面的作用，这就不是一个好的度量。所以为了得到管理层的认可，ScrumMaster和团队要一起思考我们需要度量什么指标，怎么度量以满足管理层的需要。 4. 客户的认可 软件开发的最终目的是什么？我认为是让客户高兴，即得到客户的认可。想要得到客户的认可，就需要共情（Empathy），可以换位思考，想其所想，真正解决客户的问题。这里可以参考设计思维（Design Thinking），就不展开论述了。 总结 Scrum中，认可是一个奇妙的事情。人的内心总是渴望认可，不论个体或团队。认可同时也是内在驱动的动力之一。内在驱动还有很多其他类型的动力，详情可以参见《管理3.0》（如好奇心，自主，目标，荣誉，专精，秩序，影响力，人脉，职位等等）
2014/10/17
articleCard.readMore为什么我们需要自组织团队
作者 Sigi Kaltenecker and Peter Hundermark ，译者 曹知渊 发布于 2014年9月19日 | 1 讨论 “最优秀的架构、需求和设计都出自自组织团队（self-organising）之手”，敏捷宣言（Agile Manifesto）如是说。这提出了一系列问题：什么是自组织团队？为什么我们需要他们？自组织团队有什么不一样？有什么办法可以使这种团队模式脱颖而出？ 令人惊讶的是，关于自组织团队的定义以及如何高效地支撑他们的资料很少。组织发展咨询师Sigi Kaltenecker和敏捷教练Peter Hundermark正在编写一本小册子，名字叫《领导自组织团队》，这本书将由InfoQ于2014年年底出版。 书中的一系列文章中将向读者阐述这个主题，本文是其中的第二篇。第一篇的题目是《什么是自组织团队？》，本文的关注点是“为什么我们需要自组织团队？”，而第三篇和最后一篇文章的主题则是《如何领导自组织团队》。 为什么我们需要自组织团队？ 从1980年代以来，我们经历了巨大的变迁： 政治变迁，比如苏联和东欧国家的解体； 社会变迁，比如很多国家愈演愈烈的人口迁移，以及不断提高的教育水平； 人口变迁，西半球不断提到的预期寿命和不断降低的出生率见证了这一点； 环境变迁，主要指的是全球变暖和气候变化； 技术变迁，比如医学、生物和通讯技术，催生了新一代的“数字原住民”（译者注：意为自幼就熟悉信息技术的人）； 经济变迁，从股东利益至上，到所谓金砖四国的出现，再到2008年的全球金融危机。 所有这些改变都给我们带来了新的 挑战。一个组织已经无法自主选择是否要应对这些挑战。必须要做出改变。保持现状的想法就好像试图留住秋天的落叶。一个组织要想成功，它必须充分利用这些变化带来的机遇，同时对危机有足够的准备。换句话说，一个组织必须得跟上当前市场的要求，甚至要领先一步。这很困难，因为市场变幻无常。今天的宠儿，明天可能一败涂地。昨天赖以成功的因素，一夜之间可能成为负担。 “业务敏捷性（business agility）”被证明是一个组织在二十一世纪获得成功的诀窍。改进和革新很久以来就是组织单位的必修课。手上的机会要充分利用，新的可能性要充分挖掘，竞争优势要逐步建立。 对于以上很多问题来说，自组织的敏捷团队看起来都是一剂良药。这种团队听说能： 获得更好的结果 传递更多的商业价值 比微观管理（micro-managed）的团队更加高效地协同工作 学得更快 工作中有更大的动力和乐趣 带来更高的回报 管理者们都忙着在想象自组织团队的样子，但是他们忽略了一个重要的盲点：自组织不仅是一种团队形式，更是一种管理手段。传统的“命令并掌控”的管理手段已经水土不服了，取而代之的是更多对敏捷性的要求。沉闷的官僚机构、令人窒息的控制系统、毫无意义的规划和绩效管理是这种水土不服的几个症状。 根据当代的一些研究，比如德勤领先创新中心的变化指数（The Shift Index），五个雇员中只有一个会全身心投入工作，75%的雇员缺乏动力和激情，只有15%的团队才能完全展现他们的潜力。此外，越来越多的人患上“变革疲劳症”（译者注：对组织的不断调整表现出冷漠和消极），因为很多变革动议最终都无法达到预想的目的。通常这种动议得到的回应是，“千万别再搞了”，而不是成员的积极投入。虽然没有广泛的数据支持这一点，但是各种采样调研显示，60%到80%比例的项目都终结于此。 这种令人沮丧的失败率有很多原因：缺乏透明性、同时实施太多的变革、变革推动者太弱势、缺乏反馈机制，最后但同样重要的是，太过沉湎于项目计划细节、预设的里程碑和明确的结果。不幸的是，我们身边的这些动荡，在无情地嘲弄着我们的那些计划和预测。正如Meg Wheatley试图唤醒我们的话：“我们不能再用旧世界的地图去征服新世界了。” 我们来看看上个世纪典型组织的特点和现代观点的对比，借此我们可以更好地理解哪些变革是势在必行的。 二十世纪 二十一世纪 组织是中央集权下的各种功能的集合体 组织是一整个系统 组织中的各种因素因果关系是可以预料的 复杂的关系网络 中央集权式的协调和控制是必须的 分散式的各种自我组织和自我调节的流程 等级制度和官僚机构 精简的层级网络 股东利益至上 平衡各利益相关方 追求短期利润 通过不断改进和变革，追求长期的成功 变革被动地受项目驱动 变革被视作长期的，顺势而为的行为 表一：组织的典型特征 这个表概括了Russell Ackoff早在二十五年前指出的机械性思考和系统性思考的一些关键区别。尽管这个表格有点极端化，它还是指出了过去和面向将来的两类领导技能所需要的系统性环境。这两种占主导地位的组织特征分别认同两种完全不一样的管理和领导模式带来的价值观和原则：功能化还是全盘布局，一成不变的因果关系还是复杂的思考，行政干预还是不断变革，股东利益至上还是平衡各方利益，把变革看作迫不得已的事还是所有业务的驱动力。 这样，在前一种已经固化的业务流程中，它的管理者必须自己一手设计出一个高绩效的团队。他必须有能力设定明确的目标，建立决策模式，调配资源。糟糕的是这种机械化模式所倡导的原则和价值观至今仍然大行其道。他们还是用旧学院式的实践原则领导着很多企业——甚至更糟，在大学中依然教授着这些理念。尽管我们身边不断出现新的挑战，传统的MBA仍被认为是担任经理人的关键资本。
2014/9/30
articleCard.readMore如何通过敏捷提高IT业务整合的效率(转载自InfoQ)
作者 Ben Linders ，译者 姜信宝 发布于 2014年9月30日 | 讨论 分享到：微博微信FacebookTwitter有道云笔记邮件分享 稍后阅读 我的阅读清单 在敏捷项目中，产品负责人往往被看做是业务和IT联系首要保障的人。但对于有效的IT业务整合，仅有产品负责人是不够的。来自业务、需求和组织的供应方的人们，做些什么可以提高IT和业务整合的效果呢？ 在敏捷和软件架构研讨会2014上，来自Ordina的Klasien Postma介绍了“敏捷项目不能产生有效的IT业务整合”。在她的演讲中，Klasien说明人们如何采用精益思想去决定哪个架构文档是必须的，以及当文档是必须的时候，讨论为什么在许多项目中往往是IT团队采用敏捷实践，并且在关于如何提高敏捷项目中业务、需求和供应方的参与方面给出了一些建议。 Klasien介绍了她的工作经验，她在司法委员会和荷兰税务机关这两个政府部门当中担任过不同的架构师角色。她观察到这些组织中的一些趋势，包括向更少的部门集中化，通过共享服务中心实现专业化，以及更加注重IT管理。 司法委员会采用两种团队：产品开发团队——面向供应链，专注于业务价值和项目范围；服务开发团队——面向组件，专注于质量和跨项目范围的重用性。团队使用多个backlogs以管理他们的工作并与其他团队协作。 Klasien给出一套基于精益思想的问题，可以用来决定哪些架构文档是必须的，以及何时需要它们： 谁需要这个文档？ 为什么他/她需要这个文档？ 对他/她来说这个文档的价值是什么？ 文档丢了会怎么样？ 不同类型的架构文档有不同的用处。领域架构用来做长期规划，项目开始的时候架构文档支撑项目初始化。在迭代期间使用解决方案架构以及控制架构和变更管理。 根据Klasien所说，这些就是为什么需求、供应和业务作为合作伙伴不配合的原因： 用户被称作客户，而不是同事 没有把供应方当做业务伙伴 有许多偏见，且没有足够的自信 Klasien在她的的演讲中提供了一些建议，不同的利益相关人可以参考相应建议提高业务IT整合的效果。她建议业务要意识到他们应该关注自动化，并且业务人员应该钻研自动化流程以及尽量不要反对IT。对来自需求方的利益相关人，她建议当现实和理论不符时应该去拜访执行单位，亲眼查看现状，因为现状与理论总是有偏差的，需求方还应该在制作产品规格时让真正的用户参与，不要认为IT是很困难的事情。对于供应方的利益相关人，她建议邀请产品负责人之外的用户参加演示会以及产品规格会议，并专注于简单的说明。 Klasien说，对于业务IT整合，建立在平等上的合作是最重要的。要把业务现实有效地融入到IT解决方案中，需要让思路脱离固有的模型和预定义的模式。 查看英文原文：How Agile Can Yield Effective IT Business Alignment 感谢杨赛对本文的审校。 给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。
2014/9/30
articleCard.readMore敏捷影响的量化
本文是Rally公司2013年从9629个使用Rally软件的团队中总结抽取的报告，（所有的报告是基于数据的，所以）非常有参考价值。 我简单翻译总结了一下：（英文版的报告） 全文分为四个维度: 1. 生产力翻倍 关键发现：稳定团队带来如下结果 – 提高60%的生产力 提高40%预测性 提高60%的响应能力 建议： 每个人全心投入到一个团队中 保持团队完整稳定 我的反思： 针对上面的发现和建议，结合软件开发的现状。应该加强产品化思维，减少项目方式（做项目的时候是一个团队，做完了团队就散了）。 2. 质量提升250% 关键发现： 做全Scrum的团队比不做估算的团队质量提高250% 轻型Scrum团队（只估算故事点而不估算任务小时数）整体表现更好。（文中提到针对成熟的敏捷团队） 建议： 有经验的团队可以从轻型Scrum获得最好的结果。 如果是敏捷新手，或非常注重质量，选用全Scrum 我的反思： 虽然最近一年，看板（Kanban）方法越来越火，但个人感觉看板虽然简单，实施起来实属不易（比Scrum用起来更难–貌似越简单的东西，用起来越难）。所以如果我个人推荐的话，还是考虑先从Scrum入手。 3. 上市时间（Time to Market）缩短一半 关键发现：有效控制在制品（WIP）的团队— 流程中的时间（比如用户故事在研发流程中）缩短一半 只有1/4的缺陷 但是生产力低34% 建议： 如果在制品太高了，那就降低它 如果在制品已经很低了，考虑经济驱动因素： 如果生产力到达底线（注：生产力已经不能再低了），那么不要降低在制品数量 如果上市时间（TTM）到达底线，继续降低在制品数量 我的反思： 在制品数量不能无限度的降低，当每个人的在制品是0-1时，生产力会大幅下降。经济合理的在制品数量是每个团队成员1-2 总结上面两条，当降低在制品数量没有显著影响到生产力时，继续降低在制品（WIP） 针对软件行业的大多数团队，在制品数量都是较高的。因此，降低WIP往往能带来意想不到的效果。 推荐一本好书，Don Reinertsen的《The Principles of Product Development Flow》。详细介绍了产品开发中的经典理论，有很多都是反思维了，看了很受启发。 4.
2014/9/28
articleCard.readMore谁是最可爱的人——记录敏捷之旅北京历年的组织者
Agile Tour（以下称为敏捷之旅）是一个国际非盈利性组织，于2008年成立，总部位于法国。其目的是提供一个高效有趣的敏捷开发学习途径，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。它通过一系列的活动，在全球的范围内 极大推广敏捷 分享敏捷的愿景 联合 支持 非盈利活动的背后离不开一大群‘最可爱的人“，即我们每年活动的组织者们。正是有了他们牺牲自己宝贵的休息时间和与家人团聚的时间，才能使敏捷在北京传播开来。 这篇博客主要是想感谢从2010年以来，敏捷之旅北京的历届组织者们： 2014年12月20日 （联想） =================================== Bob Jiang(姜信宝)，廉雨，喻泽高，张明，张峰，高玉峰，周园，刘芸，熊志男，金世亮，王一男，Isly，Melody 2013年12月21日 （创新工场） =================================== Bob Jiang(姜信宝)，谢钊，程嘉利，黄喆，喻泽高，李东，张布航，王立杰，王明兰 2012年12月1日（清华大学出版社） =================================== Bob Jiang，李东，Shining，李小波，蒋麒麟，黎金刚，马斌，Andy Wang，徐毅，周筱敏 2011年11月12日（京仪酒店） =================================== 李东，Bob Jiang，张雷，景兴碧，王兴华，洪志奎，周金根，王立杰 2010年10月30日（京仪酒店） =================================== 李东，Shining
2014/9/19
articleCard.readMore《偷师学艺——10个你一定要知道的创意秘籍》读后感
在亚马逊上偶然发现的一本小书，《偷师学艺》。书里面开篇的一段很好，“没有什么是原创的”。引用《圣经》，“太阳底下没有新鲜事。日光之下，并无新事。”那也就是说所有的创意都是“偷”来的。 想起来苹果不是第一个做PC的，而是抄袭IBM的个人电脑，从而取得巨大成功的。微软也没有发明图形化操作系统，而是从苹果偷来了这个很棒的创意。 这本书中介绍的10个创意秘籍，我非常认可的几点摘录一下： 写一本你自己想读的书 努力工作并且与人分享 与人为善 正好昨天也和一位好友梳理了一下自己的人生规划，该找准自己的方向，开始起航了！
2014/9/17
articleCard.readMore敏捷之旅北京2014组织者招募中
敏捷之旅（Agile Tour）是每年一度的非营利性系列会议，旨在把敏捷社区联系起来，系列会议分别在全球众多城市召开，从10月份开始到12月份结束前后历时数月。 敏捷之旅的主要目标是： 针对敏捷的大规模交流：我们在10月份的主要任务是，开展以开发实践为主题的“大众传播”。我们希望把这些内容传递到每一个有听众的地方，从而引起人们对我们新式专业方法的大量关注。 分享我们的敏捷愿景：既然敏捷是与时俱进的，那么我们在为敏捷社区贡献我们的认识、阐释及理念的同时，要对各种新视野保持开放。 本地化增长：促进敏捷领域在世界各地的领导力。 支持：协助我们的同行及当地企业采用敏捷。 你将获得的： 活动之前和期间免费培训的机会（敏捷相关或演讲技巧） 和志同道合的朋友们一起以敏捷的方式做事，从而深刻体会敏捷理念的机会 扩展自己的人脉 扩大自己在敏捷社区中的影响力 活动当天与讲师共进晚餐，一起讨论的机会 如果你对此感兴趣，很简单，发封邮件告诉我吧，我的邮箱是jiangxb@gmail.com，邮件主题为“<你的姓名> + <应募组织者或志愿者>”，正文中请包括以下内容： 姓名 公司 电话 想告诉我的话（为什么想参与到活动中啊，对敏捷之旅有什么期望啊，有什么好的建议和意见啊等等） 敏捷之旅北京的组织者，非你莫属！
2014/9/16
articleCard.readMore什么是设计思维（Design Thinking）
最近设计思维（Design Thinking）越来越多的出现在我的视线中，因此在网络中搜索了一些有关设计思维的材料。总体上我的理解为：设计思维是一个设计的过程，分为洞察-构思-原型三部分；另外这三部分不是按顺序执行的，且是迭代进行的。 本文译自https://dthsg.com/what-is-design-thinking/ 设计思维是以人为本的 关注人、客户以及他们的需求，而不是具体的技术或其他情况。 因此采用的方法有观察、访谈、头脑风暴、原型…… 在商业、科技和人文交汇点创新就是根本性的新体验创新。 用户来决定一个产品或服务是否应该存在或开始。 设计思维是重复的学习过程 在项目中，设计思维团队用迭代的方式工作：重新定义问题，发现需求，构思，打造原型，与用户进行验证。 迭代的方式实现了人文领域较高的专业知识，且支撑着多种结果。 设计思维项目包含发散和收敛阶段 设计思维让团队成员发散的思考。 发散思考的结果打造了收敛结束的基础。 设计思维是结构化的方法，沿着项目时间线定义了清晰的里程碑。 一开始项目建立于定义好的明确目标。换句话说，设计思维项目有很不确定性，因为在最后阶段之前结果都是开放的。 设计思维是原型设计 结果的有形性，体验性和验证性是设计思维的本质的要素。 原型允许最终用户在创新的早期过程参与其中。 直观感觉给予复杂挑战的最初期理解。 通常，设计思维远不止这些……
2014/8/12
articleCard.readMore海尔为什么能成为白电老大
海尔为什么能成为白电老大，暨海尔参观之行的总结： 关键词：创新，人单合一，按单聚散，6S，经典语录 最近微信上流传着很多有关海尔的评论，本人也随波逐流，上周末去了一趟海尔实地考察。下面我将细细道来我的一些观察和体验。 在海尔，听到最多的词汇是创新，并且是从海尔成立之初（1984年），创新就被植入了海尔的基因中。并且海尔非常会使用精神激励来鼓励创新，如在海尔文化展过程中，可以看到典型的启明焊枪（以个人名字命名的创新产品）。 这点让我非常震惊，没有想到一个传统的生产制造商会如此看中且鼓励创新。在海尔，每个员工都可以把创新想法发布出来，每周会有评审会审核想法。一旦创新想法通过，就可能会被载入海尔的史册。当然更重要的是他可以成为自主经营体的负责人，领导并负责这个新想法的实现。 人单合一，全称是人单合一双赢模式。人指的是员工；单指的是市场目标，用户需求，而不是狭义的订单。人单合一即员工与用户融合为一体。双赢指的是员工在为用户创造价值的同时，也体现出自身价值。即由原来的员工听公司的（执行者），转变为员工听用户的，公司听员工的（接口人）。由用户来决定自己的需求（体验）。人单合一使每个人都是自己的CEO。 按单聚散 - 员工由原来的执行者（服务指令）转变为接口人。经典的人事管理为选育用留。互联网概念下的人事管理为在线员工而非在册员工。让员工成为自己的CEO，真正地行动起来。 6S（整理 整顿 清扫 清洁 素养 安全） - 进入海尔大门后，第一眼就看到了非常熟悉的6S（原来为5S，增加一个安全Safe）宣传牌。后来听海尔的朋友介绍，在海尔，6S已经融入到了每天的工作当中，每天班组都要站在大脚印上进行自省。 参观海尔文化展过程中，记录了几句张首席非常经典的话： 企业是人，文化是魂。 13条不准 有缺陷的产品就是废品。 斜坡球体论（上升力是创新，止动力是基础管理） “走出去”有风险，但不“走出去”风险更大。 能阻挡我们的只有我们自己。 参观完海尔后，我问了几个同行的同事什么感受。几位同事都感慨道，今天参观的是互联网公司吧，海尔彻底颠覆了传统制造商的做法，真没想到，等等。 写在最后： 在去青岛的路上，和马老师建议参观完海尔斤进行一次全体的回顾会议（复盘）。马老师欣然同意让我来引导，非常感谢马老师的信任。在整个回顾过程中，我采用了ScrumGathering中国期间学到的4F方法，即Fact（事实），Feeling（感觉），Finding（发现）和Future（未来）。我设计的4个问题为：1. 在今天的参观过程中（包括海尔文化展和下午的海尔大学交流环节），你都看到了什么，听到了什么？ 2. 每个人用1-3个词总结今天参观后的感受。 3. 如果把海尔大学和京东大学做一个比较和联系，你会有什么发现？ 4. 回去之后你会做点什么？ 各位京东大学的同事们，在今后的培训当中，你们也可以尝试4F方法，和ORID（焦点汇谈法）很相似，但很好记，也很容易使用。
2014/7/8
articleCard.readMore敏捷推荐书单（1）
最近有几个朋友找我推荐敏捷的书单，借此机会也整理一下自己看过的敏捷书籍。希望能对敏捷刚入门的朋友有些作用。这次推荐书单共有3本书，分别是《Scrum精髓》（极力推荐），《Scrum敏捷软件开发》，《敏捷项目管理》。 《Scrum精髓》 这本书可以说是针对敏捷，特别是Scrum而言是一本宝典（Bible）。书中不仅包含敏捷原则（不同于敏捷宣言对应的12条原则），这些原则是作者结合精益软件开发、经济学原理和敏捷12条原则综合得出的敏捷核心原则（如管理库存，关注闲置工作而不是闲置人员等，具体内容详见第3章）。并且本书中还包含管理者在敏捷环境中应该怎么做，作者结合自己多年的管理经验（从项目经理到职能经理到CXO等）得出作为管理层，在Scrum中应该扮演什么角色。（详情参见第13章）总之，这是一本不可多得的敏捷好书，在亚马逊上长期占据第一的位置。推荐指数，五颗星！下面是编辑推荐内容。 短短几年时间,Scrum 跃升为敏捷首选方法,在全球各地得以普遍应用。针对如何用好、用巧这个看似简单的框架,本书以通俗易懂的语言、条理清晰的脉 络阐述和提炼出 Scrum 的精髓。 全书共 4 部分 23 章,阐述了七大核心概念:Scrum 框架,敏捷原则,冲刺,需求和用户故事,产品订单,估算与速率,技术债;五 大角色:产品负责人,ScrumMaster,开发团队,Scrum 团队结构,经理:Scrum 规划原则及四大规划活动:多层次规划、产品组合规划、产品规划和长期规划; 冲刺四大活动:规划、执行、评审和回顾。 本书取自作者十多年的实践经验,对员工个体和管理层都具有重要的指导和 参考意义,可以帮助企业导入 Scrum 方法实现敏捷转型,从而在动态的商业环 境中以积极的心态拥抱变化,做出优秀、卓越的产品,成就创业、守业、常青基业。 《Scrum敏捷软件开发》 这本书是我读的第一本敏捷书籍，第一次读的时候感触不是很深。不过每一次翻阅都有更深一层的感悟。本书尤其适合组织进行敏捷转型时作为参考。比如书中提到的ADAPT模型，企业转型中成立ETC社区，针对人力资源或PMO等部门在敏捷转型时该做些什么。Mike Cohn的书值得一读。 编辑推荐：本书是Mike Cohn的三大经典著作中影响最为深厚的作品，也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考。作者把自己近15年的敏捷实践经验，从更高的思想层次对敏捷和Scrum多年来的经验和教训进行深入而全面的梳理和总结。本书适合经理、开发人员、教练、ScrumMaster、产品负责人、分析师、团队领导或项目领导。 《敏捷项目管理》 这是一本不可多得的在项目管理领域如何应用敏捷的书籍。传统的项目管理是经典的项目管理铁三角（时间、成本和范围），而敏捷项目管理有了新的三角形（价值、质量和约束）。在敏捷项目中，是以价值为核心，质量为本，在约束（时间、成本和范围）条件内完成项目。本书还介绍了传统项目管理更多的是固定范围，而时间和成本不固定，但最终结果是时间和成本都大大超过了预期。在敏捷项目管理中，时间和成本固定（固定的时间盒，人员固定即成本固定–软件开发中人力成本占据大部分），而范围不固定。这样敏捷团队可以专注于高优先级的需求（在产品列表中靠上的需求），从而即使我们没有完成所有需求（在既定的时间和成本内），我们也是完成了最有价值的部分。
2014/6/20
articleCard.readMoreScrum活动之每日例会（站会）
昨天发了一篇博文，介绍“每日站会中常见的错误与误区”。有小伙伴问，那些都是错误的做法，那么正确的每日站会应该怎么开？下面就说一下在Scrum中，每日站会是怎么开的。 在冲刺期间的每一天，理想的做法是在每天同一时间，开发团队举行一定时间范围内（不超过15分钟）的每日例会（Daily Scrum，参见下图）。这个检视与调整活动有时也称为“每日站会”（Daily Stand-up），因为大家站着开会可以使会议简明扼要。 举行每日例会的一个常见做法是ScrumMaster负责确保会议更顺畅，每个团队成员都要轮流回答3个问题，让其他团队成员了解情况： 在上次每日例会之后我完成了什么？ 在下次每日例会之前我计划做什么工作？ 有什么障碍让我无法取得进展？ 通过回答这些问题，每个人都能了解全局，知道发生了什么事情，实现冲刺目标的进展如何，对当天的工作，是否需要修改计划，有什么需要处理的问题。每日例会是必不可少的，能够帮助团队管理一个冲刺内快速、灵活的工作流。 每日例会这个活动不是用来解决问题的。相反，很多团队选择的做法把问题的讨论放到每日例会之后，和一小部分感兴趣的人讨论。每日例会也不是传统意义上的状态会议，尤其不是以前那种由项目经理召集、为了解项目最新状态而举行的会议。不过每日例会对于开发团队成员交流冲刺Backlog条目的状态也是可能有帮助的。每日例会主要是一个检视、同步、适应性地制定每日计划的活动，以帮助自组织团队更好地完成工作。 Scrum曾经使用过术语“猪”和“鸡”来区分在每日例会中哪些人应当参与，哪些人只要站在旁边看就行了，不过这两个术语现在已经不用了。这两个农场动物术语来自一个老笑话（这个笑话有几个不同的版本）：“在早餐吃的火腿鸡蛋中，鸡是参与者，猪是全部投入了。”显然，Scrum使用这些术语是为了区分参与者（鸡）和为了实现冲刺目标而全力投入的人（猪）。在每日例会中，只有猪应当发言，如果有鸡参加例会的话，应当作为旁观者。 我发现一种很有用的做法，即把Scrum团队中的每个人都看成猪，不是猪的，就是鸡。当然，不是每个人都赞成我这个观点。例如，产品负责人不需要参加每日例会，所以有些人认为他是鸡（其中的逻辑是，如果不需要参与，又怎么可能“全力投入”呢？）。我认为这好像不对，因为很难想象作为Scrum团队的一员，对于冲刺的最后结果，产品负责人的投入怎么可能比开发团队更少呢？如果在Scrum团队中使用猪和鸡的隐喻，是行不通的。 下面是关于Daily Scrum的另一种描述。（摘自ScrumAlliance官方网站说明） Activity: Daily Scrum The Development Team is self-organizing. The Development Team uses the Daily Scrum meeting to ensure that they are on track for attaining the Sprint Goal. The meeting takes place at the same time and place every day. Each Development Team member gives three bits of information: What I have accomplished since our last Daily Scrum.
2014/6/19
articleCard.readMore敏捷原则（1）——来自《Scrum精髓》
计划驱动的开发得名于试图一开始就想明白、事先规划和考虑用户可能需要的最终产品中的所有特性并敲定这些特性的最佳构建方式。它的思路是：计划制定得越好，对产品的理解就越好，执行也就越好。计划驱动过程常称为“顺序过程”，因为每个实际工作者按照顺序依次执行，在完整的需求分析之后是完整的设计、编码∕构建，然后是测试。 对于明确定义、可预测且不可能发生任何重大变更的问题，计划驱动开发方式是很适用的。可问题是，大多数产品开发工作根本就不可预测，刚开始的时候尤其如此。因此，虽然计划驱动过程让人感觉有条理、可以解释清楚、可以度量，但这种印象会产生一种错误的安全感。毕竟，产品开发很少是按照计划进行的。 对很多人来说，计划驱动的顺序过程是合情合理的：首先是理解问题，然后设计、编码、测试、部署，全都按照明确制定的计划执行。他们相信传统开发过程是可行的。如果使用计划驱动的方法没有效果，大多数人都会觉得一定是我们自己做错了事。即使计划驱动的过程反复产生令人失望的结果，但很多组织仍然还在沿用，傻乎乎地相信只要能够做得更好一些，结果就会有所改善。然而，问题并不在于执行。问题在于计划驱动方法所奉行的理念根本无法适应大多数产品开发工作所固有的不确定性。 另一方面，Scrum则奉行另一套不同的理念，该理念很好地处理了因不确定性程度高而很难做出宏观预测这个问题。本章所描述的敏捷原则来源较多，包括敏捷宣言（Beck et. all，2001）、精益产品开发（Reinertsten 2009b；Maryand Tom Poppendieck，2003）和“Scrum指南”（Schwaber and Sutherland, 2011） 敏捷原则可以分为如下几类： 我们先讨论产品开发固有的可变性和不确定性的相关原则。再讨论如何平衡预测和适时调整之间的关系。然后着重讨论认知原则和未完工产品的管理原则。本章结束时再重点介绍进度和性能的相关原则。
2014/6/18
articleCard.readMore每日站会的常见错误与误区
每日站会是Scrum中非常重要的检视与调整活动。因此在很多非Scrum的方法中也常常引入每日站会实践，不过如何进行一个好的每日站会也不是那么容易的。下面列出一些常见错误与误区，希望各位朋友引以为戒： ScrumMaster每天提醒大家开会。每日站会应该是每个人的习惯，融入到每天的工作当中。 每日站会成为向ScrumMaster的状态汇报会。要记住每日站会来自于团队，服务于团队。 不准时开始。 总是有人迟到或干脆不参加。 ScrumMaster挨个人问3个问题，每人汇报个人的状况。 会议总是很长时间（超过15分钟，甚至是30分钟）。 团队成员之间不信任。 害怕有冲突。 总有人不是很负责。 每日站会变成一个很无聊的会议。 不是每天都开每日站会。 团队没有认识到每日站会的价值。 开会不聚焦，总有一些八卦或小道消息。 ScrumMaster或产品负责人在指导团队该做什么。 团队成员没有准备好开每日站会，开会时现想那3个问题。 每日站会的时候去解决问题。 团队成员不清楚其他人在说什么。 一个人总是不断地在插话，干扰其他人。 有人每日站会上打电话（或接电话） 每日站会时，都对着ScrumMaster说话。（貌似一个状态汇报会） 团队成员对于自己做过的事情模棱两可，其他人也不清楚他在做什么。 每日站会时，非团队成员来干扰开会。 朋友们，在每日站会时，你还有碰到哪些问题呢？欢迎来信交流。
2014/6/18
articleCard.readMore管理3.0工作坊总结
在胡莱游戏的管理3.0工作坊那可真是人山人海，红旗飘扬。那么说到这里得先感谢一下这次的场地赞助方——胡莱游戏。 接下来呢，还要感谢王宇和申健给大家带来的工作坊，两位来自天津敏捷社区的朋友。下面开始回顾内容： 首先是开场（破冰）。破冰比较独特，首先是介绍了团队的最佳规模（大小），以及为什么是这个数字（5）。然后让大家自组织成5人的团队（设定了一个规则，根据多样性得分）。 接下来介绍为什么是管理3.0.在《管理3.0》书的前言中，作者提到管理1.0是层次体系（如科学管理等），管理2.0是流行（如平衡计分卡、六西格玛、约束理论等），管理3.0是复杂性（如领导而非管理）。在PPT中，Jurgen做了一个形象的比喻，管理1.0就像一部机器，管理2.0就像一场运动，管理3.0就像是社区。其实管理1.0 2.0 3.0是一个演进蜕变的过程，是适应那个时代的合适的管理产物。王宇还提到管理貌似可以分为两大派：彼得德鲁克（感性派）和戴明（理性派）。 继续敏捷管理之前，需要简单梳理一下敏捷那点事儿。比如Scrum的核心是什么（推荐阅读《Scrum精髓》、看板的核心是什么、什么是精益创业以及什么是传递幸福。（这里有个不错的游戏，让大家感受每种方法的规则和原则，确定性和不确定性之间的关系）Jurgen还多次引用VersionOne公司关于敏捷的调查（这个调查我也会多次引用）。 介绍完管理和敏捷之后，就进入正题（管理3.0），即敏捷管理。在管理3.0中，Jurgen把管理分为6个不同的视角（赋能团队、激励员工、调和约束、培养能力、壮大组织结构和全面改进），这6个视角也是管理3.0的核心。作者通过理论加实践的方式解答了在敏捷的环境下如何进行管理。 在复杂性思考的内容中，有介绍到结构和行为模型（这是Jurgen独创的，参考了多个复杂性模型得出的，如Cynefin，认同度和确定性矩阵模型等）。 然后从8个方面解读了复杂性思考这个复杂的问题。 激励员工方面，介绍了一个十大内驱力因素的游戏。可以帮助管理者快速找到员工的内驱力是什么，以便于很好的激励员工。另外一个游戏是通过不同的场景（行为）去探索某员工的特质，模拟现实生活中如何去和员工交流以获取信息。 赋能团队主要介绍了7个不同的授权级别。依次为：告知、贩卖、咨询、商定、建议、征询和委托。这里使用一个委托扑克的工具，让学员很好的体会针对不同的事情采取不同的授权级别。 简单回忆到这里，管理3.0是复杂的，应用更是复杂的。使用作者的一句话“所有模型都不对，但有些有用”。大家在学习一个新模型的时候要用判断性思维，选取其中的精华或本质。
2014/6/15
articleCard.readMoreRegional ScrumGathering China总结-内容篇2
上篇总结了大会第一天的内容，接下来总结一下大会第二天的内容。 主题演讲：经济合理的Scrum （下载地址） Ken Rubin的主题演讲，我跟的时间最长，并且PPT是我来负责翻译的（非常感谢徐毅帮忙校对）。开篇Ken用一个自己和儿子在餐馆的对话引出价值的思考，从而引出主题演讲的大纲（经济合理的Scrum），即如何用Scrum产生更好的经济价值。演讲中主要意思是说虽然很多组织在采用Scrum，但他们并不成功，因为没有很好的理解敏捷核心原则。那么敏捷的核心原则是什么？PPT第11页提到，敏捷的核心原则为：可变性和不确定性、预测和适应、经证实的认知、在制品（WIP）、进度和执行（注1：在《Scrum精髓》第三章敏捷原则中详细介绍了以上的原则）（注2：Ken结合敏捷的12条原则和Reinertsen的产品开发流的原则，重新梳理了敏捷原则）。 Ken在提完这些敏捷核心原则后，也紧跟潮流提到了反脆弱以及反脆弱就是敏捷的好处。（即组织采用敏捷之后可以从混乱当中受益） 这个演讲分为三大部分： 开发过程中忽视或误用敏捷核心原则 未能在价值链从头到尾运用敏捷原则 未能以经济合理的方式组织团队（由于时间安排，这一条未提及） 写到这里，我想起来在Jim Highsmith的《敏捷项目管理》中提到敏捷项目管理的铁三角中，价值是一个核心的维度，即Scrum是以价值为核心的。在产品开发中，我们需要时刻记得初心是什么。 开发过程中忽视或误用敏捷核心原则： 变化发生时，业务人员和技术人员对于变化的不同理解（误解），经济合理的变化是如何管理的（如何做）。 对于及时制（JIT）的误解，如何更好的使用JIT方式。 识别库存浪费，在产品开发中，库存在物理上和财务上都不可见。这个时候如何管理库存。 关注闲置工作而不是闲置人员。经济合理的规划。 未能在价值链从头到尾运用敏捷核心原则： 下游系统不搭配 内部管理不搭配（小插曲：在翻译这页PPT时，我有观察到左下角小松鼠的图片。问过Ken之后果断添加上“吃着碗里的，惦记着锅里的”-笑点啊） 销售不搭配 组合计划不搭配 合作伙伴不搭配 未能看到全局 最后的总结也超棒： 执行所有的Scrum实践和证实过的方法，不能保证成功（必要但不充分）。要想成功，运用Scrum需要基于敏捷核心原则，以及采纳允许合理折衷的经济框架。 《Scrum精髓》我要购买
2014/6/14
articleCard.readMoreRegional ScrumGathering China总结-内容篇1
每年的ScrumGathering大会都听不了几个演讲，今年略有一些改善，认认真真地听了几个，而且还非常非常不错的演讲。我也愿意分享给各位未能参会的朋友。 工作坊：Agile1001敏捷开发项目实战训练营 这个工作坊是我和王立杰一起完成的，一共分为2大部分。第一部分是用户故事编写工作坊，第二部分是用影响地图的方式组织需求。当初设计的时候是从滕振宇CSM课程那里“偷”的做法，先挖坑，再填坑。那么我们的第一部分就是先挖坑，看看大家的用户故事都是怎么写的，多少都会有一些错误的做法，甚至有的人写完了，就不记得自己为什么写这些故事。第二部分就是来解决这个问题，影响地图可以让我们时刻记住目标是什么，（即我们的方向）同时也不会忘记我们是在为什么用户角色完成什么影响。具体的内容可以参考PPT下载地址。 讲师培训：如何准备一个精彩的培训 美女培训师刘颖丹给我们带来了一场非常精彩的培训，主要内容为如何准备一场精彩的培训。开篇先抛出一个模型ADDIE（来自美国培训师协会的），分别是Analysis，Design，Develop，Implement，Evaluate。准备一场培训是ADDI这样一个循环，而Evaluate和每个环节都有交叉。 开场破冰也是蛮有意思的，首先是分成4个组，每个组讨论关于ADDI的五个小窍门或技巧。然后使用外交大使的形式重新分组进行思想碰撞。最后每组分享从其他组“偷学”的内容。 接下来，对培训学员进行分类研究（来自九型人格分析），把学员分为三类：脑型（思考派），心型（感觉派）和腹型（行动派）。针对不同类型的学员，可以安排不同的培训活动和内容。 后面通过一个对比的视频，大家总结如何搭建一个好的培训。以及在总结过程中使用了4F和4R的回顾方法，相比ORID这两个方法更易上手和使用。并且现场让大家有2次的练习机会。
2014/6/10
articleCard.readMore三个关键的敏捷风险管理活动
我们都知道软件开发有风险。我们在用不确定的一套需求并在非常紧密的时间表内创造着新事物。在这之上，我们还不得不担忧未知的依赖性、突发的市场变化以及人员的轮换！We all know that software development is risky. We’re creating something new, with an uncertain set of requirements, in an often-tight timeframe. On top of that, we have to worry about unknown dependencies, sudden market changes, and personnel shifts! 那么这也难怪许多人相信没有某种方式的风险管理策略，他们闪亮的新项目，还有声誉，很快就会受害。这就是困惑点。如Scrum和看板的敏捷框架根本没有显式地提到风险——因此敏捷组织应该在敏捷框架之上实施一套正式的风险管理流程吗？回答是以前，考虑一下。It’s no wonder then that many believe that without some sort of risk management strategy, their bright and shiny new project will tarnish quickly, along with their reputation. And this is where the confusion sets in.
2014/6/3
articleCard.readMore《Scrum精髓》内容简介
编辑推荐: 上市以来雄踞亚马逊敏捷类畅销书榜首,热评如潮 Scrum 精髓,一点就通, 一本就够 揭示同类书不告诉你的主题和秘笈 适用于大多数敏捷过程的实用指南 适合团队成员、经理和执行负责人阅读的知识读本 如果想用 Scrum 来开发足以引爆流行的产品和服务,本书就是你梦寐以求的 完全参考。作为业内领先的敏捷教练和培训师,Kenneth Rubin 用通俗易懂的语 言和丰富的实例与我们分享他十多年的实践经验,诠释 Scrum 的价值观、原则 和实践,描述一些灵活、可行的方法帮助我们用好 Scrum。 针对 Scrum 新手和达人,本书从团队、产品和产品组合这三个层面来介绍、 澄清和深化 Scrum 的相关原则和应用。Rubin 曾帮助数百个组织成功应用 Scrum, 积累了相当丰富的实践经验和表达能力。作为这些经验和能力的结晶,本书图文 并茂,通过通俗易懂的描述和两百多幅图对 Scrum 进行了阐述,这些图采用的 是一种全新的视觉图标语言,用于描述 Scrum 的角色、工件和活动。 本书可以帮助团队成员、经理和执行主管了解 Scrum 常识,掌握可以拿来即 用的通用词汇表,充分攫取 Scrum 的潜力,最终实现优秀团队能够做到持续、 稳健发展的目标。 内容简介: 短短几年时间,Scrum 跃升为敏捷首选方法,在全球各地得以普遍应用。针 对如何用好、用巧这个看似简单的框架,本书以通俗易懂的语言、条理清晰的脉 络阐述和提炼出 Scrum 的精髓。全书共 4 部分 23 章,阐述了七大核心概念:Scrum 框架,敏捷原则,冲刺,需求和用户故事,产品订单,估算与速率,技术债;五 大角色:产品负责人,ScrumMaster,开发团队,Scrum 团队结构,经理:Scrum 规划原则及四大规划活动:多层次规划、产品组合规划、产品规划和长期规划; 冲刺四大活动:规划、执行、评审和回顾。 本书取自作者十多年的实践经验,对员工个体和管理层都具有重要的指导和 参考意义,可以帮助企业导入 Scrum 方法实现敏捷转型,从而在动态的商业环 境中以积极的心态拥抱变化,做出优秀、卓越的产品,成就创业、守业、常青基业。 《Scrum精髓》试读样章下载
2014/5/12
articleCard.readMore影响地图工作坊的反思
2014年5月11日下午在汽车之家敏捷1001公开课第六次分享内容为“影响地图实战工作坊”。非常感谢谢钊帮忙整理的会后记录回顾。不过对于影响地图（Impact Mapping）我还想再补充几点： 1. 影响地图的作用 影响地图，它可以很好得把战略目标（不论是公司级的或产品、项目级的）和工程师的日常工作有机结合起来。并且以可视化的方式呈现在所有人面前。这样一来，当有新任务涌现出来的时候，我们只需要对照影响地图，看看它是否满足某个角色对于目标的影响。如果不是的话，那么这个任务就需要以后处理或抛弃掉。 另外，影响地图也是战略和发布、迭代之间的良好润滑剂。它可以使团队更清楚地做正确的事情，而不是正确地做事。 还有，影响地图不适合用于维护项目，比较适合新产品的探索（不确定性较高的项目）。并且影响地图需要资深的技术人员和业务人员共同参与编制。 2. 如何编制影响地图 在这次工作坊中，大家在编制影响地图的时候碰到几个问题。整理如下：（也非常欢迎大家共同来交流） 影响地图中的影响（HOW）怎么写？ 首先我们要理解影响地图的结构：目标，角色，影响和功能。那么影响是什么？影响就是某个角色对于我们目标所产生的影响（可以是正向或负向的影响）。比如这几个问题可能会帮助你更好的理解影响。_角色的行为应该如何发生改变？某角色如何帮助我们实现目标？他们如何妨碍或阻止我们实现目标？_这些都是影响。同理，对于功能（WHAT），就是对于某个角色为目标所产生的影响，我们可以通过什么方法实现。 影响地图中的目标怎么确定？ 对于一个完整的影响地图，目标是至关重要的。那么一般情况下，如果目标不明确的话，我一般建议可以为了目标而单独准备半小时或更长的时间（视目标的复杂度而定）。对于目标的大小，可以是公司的战略级目标，也可以是某个产品或项目级别的目标。对于目标的规模，如果是互联网公司，建议可以设定3个月到6个月时间的目标。如果是传统行业，可以是6个月到12个月的目标。当然，这个只是一个参考，需要根据具体的情况而定。 3. 最后还要介绍一个非常重要的方法——帕累托法则。 帕累托法则，也是我们常说的二八定理。为什么介绍这个法则呢？这是因为我们在做事的时候不可能尽善尽美，做到十分完美。那么我们可能会需要花20%的精力来努力获得80%的结果，就可以了。最后那20%的结果，往往是不值得付出（投资）的。对应于影响地图中，也是一样的道理。我们要记住，影响地图是动态的，涌现的。这个地图不是说画好了，大家照着办。而是时刻提醒我们这是假设，需要去验证。一旦验证失败了，快速的转到其他假设。如果验证成功，那么基于此我们还需要深度验证并巩固我们的结果。 总之，影响地图是一个非常好的工具。它可以有效地链接目标与任务。推荐大家都看看这本书。
2014/5/12
articleCard.readMore知识的诅咒Curse of Knowledge
4月22日23日24日听了滕振宇的CSM课程，课上他提到一个词——知识的诅咒（The Curse of Knowledge），听上去蛮有趣的一个词汇。回来做做功课深入学习一下。 从互联网上查了几个解释之后，回想起10年前自己混BBS的一个场景。我经常在java板块上冒泡，所以常常会看到诸如“这个怎么编译不过啊？”，“我的HelloWorld怎么无法运行啊，提示错误为’ClassNotFound’”。好吧，错误都很明显了，就是类找不到，怎么还会在BBS上问？不过现在看来，当时的我就处于知识的诅咒当中。因为我已经掌握了一些java基础，所以知道这些错误是怎么回事并会很容易的干掉这些错误。那么我就不能理解怎么还会有人问这么笨的问题。 互联网上最多的例子是：当我把一首最熟悉的歌打拍子给对方听，本以为对方有50%的概率能猜出来（即使这首歌是世上只有妈妈好这么简单）。对方仍然满脸迷茫，根本猜不出来。实际猜出来的概率只有2.5%。这是因为敲的人心里已经有了答案，所以当敲的时候，他以为对方也知道答案。如果让刚才听的人换过来敲拍子的话，基本上是同样的结果。（上述例子来自《粘住》一书） 知识的诅咒可以用下面这个定律来说明——著名的科幻家阿瑟·克拉克有一句名言（也称为克拉克第一定律）： 如果一个有名望的老科学家告诉你某件事情是可能的，那么他很可能是对的。如果他告诉你某件事情是不可能的，那么他极有可能是错误的。 \====以下摘选自互联网==== 所谓成也萧何败萧何，“知识是一把双刃剑”这个道理在心理学领域其实并不新鲜，《Made To Stick》上 面就提到这样一个经典的实验：A心里想一首曲子，然后用打拍子的方式打出来，B听着A的拍子要去猜测A打的实际是哪个曲子。参与者选的是一些非常简单的曲 子，如“世上只有妈妈好”（此处根据中国国情稍加演绎）。这个实验的亮点在于，往往A认为“那么简单的曲子”怎么可能听不出来呢？而实际上B听了却就是猜 不出来。A对B能否猜中的概率估计，与B实际猜中的概率之间，有一个巨大的落差（A以为50%的人能猜出来，而实际上只有可怜的2.5%）。 原因？因为A心里本来就知道答案（曲子本来就是A定的），所以对于A来说这是“显然”的，但B只听到拍子，对B来说再简单的拍子也并不是“显然”的。关键在于，由于A心里明知答案，就无法去设想不知道答案的B听到那样的拍子时是什么感觉，也就无法真正准确地推测出B猜中的概率了。 实验者把这个现象称为“知识的诅咒”：由于知道某个知识，反而影响了判断。在以上的实验当中，如果A自己并不知道曲子，（曲子是实验者选的，拍子也是实验者打的），那么A就能够体会到B的感觉了。
2014/4/27
articleCard.readMore《示人以真》读后感
在写完《示人以真》读书笔记后，又进行了深刻思考。 1. 以终为始 不管做什么事情，都要有目标，并能以终为始。就好比书中说到的不要担心失去生意，那么我们去谈生意的目标是什么。谈生意最终目的还是需要能够解决客户的问题，那么我们就要怀着一颗初心，始终抱着为客户解决问题的心态。在与客户谈生意的时候，时刻想着如何能真正为客户解决问题，让客户感受到你的诚意。打个比方，比如我的3年规划是一名专业培（咨）训（询）师，那么从现在起，就要把自己当做培训师，抓住一切机会进行练习。 2. 知之为知之，不知为不知 《论语》，知之为知之，不知为不知。在客户面前也要这样。如果自己不知道的事情，一定要勇于承认自己的不知。今天在Daniel的课程上，感触最大的就是。不知道不知道的，和知道不知道的区别。如果不知道不知道，那么从何下手？Google也没有目标啊。变革艺术家就是需要让不知道不知道变成知道不知道，把新鲜的思想概念带进组织，点燃大家的求知欲。 3. 真诚诚实 为人要真诚。人之初，性本善。身在江湖，要以真面目示人。
2014/4/22
articleCard.readMore《示人以真》读书笔记
知道这本书是非常偶然的，在阅读帕特里克 兰西奥尼的《破除团队藩篱》一书时，无意中看到书后有推荐的书目，当时就被宣传语给击中了。 一位在所在地区小有名气的大型咨询公司的项目经理，却总被一家规模远小于自己的小型咨询公司竞争对手打得焦头烂额。可就在这一年，这家小公司的管理者却意外地宣布退出了，于是这位项目经理有机会接管这家公司。在经营这家小公司，梳理“宿敌”的“遗产”时，这名项目经理却惊奇地发现，让自己对手成功的原因竟是如此简单…… 怎么样？如果你心系咨询、培训并想在这个行业大展宏图的话，那么看了上述的文字一定心里老痒痒了。没错，我和你的心情是一样的，因此我迅速的下了订单买了一本。 下面我就列举该书中最最核心的思想（咱不说故事了）： 核心思想：裸式咨询 在进行咨询服务时，咨询顾问常常有如下3个担忧： 担心失去生意 担心出洋相 担心露怯 针对这3个担忧，分别有一些相应的原则可以遵守并消除担心。 担心失去生意 牢记咨询，忘记销售 把生意放在脑后 直言不讳 以身涉险 担心出洋相 问“傻”问题 提“傻”建议 接受自己的错误 担心露怯 用于承担责任 事事以客户为中心 尊重客户的工作 给客户打下手 看了上面的原则后，是不是还有疑问？有问题？是的，好几个原则我看了以后也不理解。没关系，买一本书细细地看一遍。我相信你会有收益的。
2014/4/17
articleCard.readMore初探Scrum度量
经理会要求收集和产生很多测量和报告，而对于经理来说，这正是一个真正的好机会，确保只有那些有益于价值创造流程的那些测量被捕获和汇报。当然这个目标也需要确保测量和回报的过程符合Scrum的核心价值和原则。 Scrum有几个重要原则，这些原则可以指导经理怎样处理测量和报告。下面是几个例子： 1. 关注闲置工作，而不是空闲员工。为了达到这个原则，要监测工作流什么时候被阻碍了，有多频繁，而不是监测你有多擅长让大家保持忙的状态。比如测量生产周期，会展现工作开始时间和结束时间的间隔。如果生产周期在增长，那么你就需要研究一下为什么了。 2. 通过可工作的、经过验证的资产衡量进度。如果你没有交付人们想要的产品，没超预算，按时交付这些事情还要紧吗？关注对交付价值（可工作的、经过验证的资产）的衡量，但也不要忽视交付价值所需要的参数（时间、范围、预算和质量）。 3. 组织快速反馈的流程机制。所以也需要考虑用你的测量方法来表征快速学习周期的进程（假设、构建、反馈、检视以及适应）。 4. 最后一种测量是创新核算的核心。创新核算对于任何在极端不确定条件下创建产品或服务的组织都是有效的（Ries 2011）。创新核算使用可行的指标评价我们学习的速度，并作为创造商业价值结果进度的关键测量。创新核算基于以下三个步骤： 4.1 创建一个最小化可行产品（MVP），基于组织或产品目前状况制定真实有效的衡量指标基准。 4.2 执行一系列增量式的产品改进，使指标在基准线向着理想或期望的价值进展。 4.3 如果测量指标显示产品正朝着期望的目标产生显视化的进展，那么就沿着当前的轨迹坚持下去；否则，需要转型到新的策略上，并重新开始这个过程。 \======================== 以上文章摘取自《Scrum精髓》中文版第13章
2014/4/11
articleCard.readMore看了民国时期的小学课本，不禁为现代教育而哭(转载)
总结几点非常好： 1. 人要有职业，就好比猫抓老鼠，狗看大门。 2. 整洁。古人云：一屋不扫，何以扫天下。因此整洁从个人做起。 3. 友爱 4. 投桃报李 5. 路不拾遗 \==========================华丽丽的分割线 本文转载自《读书文摘》 偶尔看到几册印于民国十一年（即1922年）的线装小学课本，不禁震撼!不禁为当今的中国教育汗颜，不禁为中华民族的未来深深忧虑!民国年间，兵荒马乱，人心却淡定。人有信念，下有常识，小学课本集二者于一身。老课本的编著是民间的，无关君王军阀权贵，透着民众皮肤上的冷暖，不呼口号，不居高临下，不繁文缛节。仁、义、礼、智、信，情趣，家国之源、江山之远、永恒之义，多在平白明净的故事之中。 教育的最大功能是使生命产生敏感。翻阅这几册线装小书，景深里都是天地之悠悠。 在此，我择其有图画有味道的几篇课文，配以拙文，分享于人，致敬民国童年。 第一课 职 业 【课文原文】猫捕鼠，犬守门，人无职业，不如猫犬。 一十八字，道出生命的庄重。 进化的自然选择，适己而利人，善哉。 不可无职业，也不可职业乱窜。犬捕鼠，多管闲事；猫看门，形同虚设。 世上职业千万，有需要就有职业；可世上好职业只有一种：喜爱又能谋生。 各司其职，便能各尽所能；按劳分配，或能走向按需分配。这些宏大的道理和主义，猫犬不懂，却能身体力行。 第六课 整 洁 【课文原文】屠羲时曰：凡盥面，必以巾遮护衣领，卷束两袖，勿令沾湿，栉发必使光整，勿令散乱。 教一件事，先教方法。道理在事体里，厚积薄发。据称联合国一份文件用五种官方文字打印，中文最薄。 语言也可整洁。 外看是仪表，内中透情境。 一个人，一亿人从小“勿令沾湿，勿令散乱”，蕴蓄华夏男儿的堂堂仪表。 第十一课 友 爱 【课文原文】徐湛之出行，与弟同车。车轮忽折，路人来救。湛之令先抱弟，然后自下。 寥寥数语，淡淡白描，人、事、观点都有了。 众人平素相似，不一样在非常时刻。危险、利益、困顿，最考验人。 这一课让我们看到什么呢？车与路都得适时检修；路有不平，人施于手；先救弱小，再自救。事小道理大，放之于雪灾、地震、车祸、旱涝、战乱而皆准。 道路决定车轮，车轮决定远方。 只是今夜城市车流里的广播正唱：心在远方，堵在路上。 第十五课 投 报 【课文原文】孙赵二女，同校读书。孙女得新书，持赠赵女。赵女取纸笔报之。 此册封三印有商务印书馆一段话：“教科书所言事实以家庭教育为主，兼及社会，皆日常习见习闻者。取材颇合儿童心理，书中间涉女子事，尤便男女共校之用……” 所以此课不只是讲孙赵二女的礼节，还在讲这个国度封建了几千年后另一半人的学堂梦想。她们是女童，她们是母亲。西方哲人曰：“一国之兴衰不是看一国之君，而是看一个个家庭的母亲。母亲哺乳了孩子，教育哺乳着母亲，谁哺乳教育呢？” 十年树木，木渐成林。光阴沉淀，积为年轮。 投桃报李，远古至今的绿色箴言。 第十六课 不 拾 遗 【课文原文】王华行池畔，见地有遗金，华置金于水边，守其旁，待遗金者至，指还之。 夜不闭户，路不拾遗，是俗世温度计上的一个温暖时刻。在川流不息的路上，在更深人静的夜里，站着人世的荣耀。 民国那会儿，军阀运辄大打出手，城乡多见兵荒马乱。大道阡陌之间，草莽英雄，世相奔逐。偏偏那一日静静站着个叫王华的童子，他守在池畔，守着金子等一个陌生的路人。读者看到他的等待，千万个如他的童子一起等待。这个简单的故事，复制为民国国民生长的一则信念。 不以黄金为最贵的年代，就是黄金年代。 第十七课 御 侮
2014/4/9
articleCard.readMore谈谈SAFe大规模敏捷框架（Scale Agile Framework）
这几天Ron Jeffries写了两篇《SAFe good but not good enough》和《Issues with SAFe》，引爆了敏捷社区关于大规模敏捷框架（SAFe）的讨论。 我的意见是不管SAFe好不好用，只要是解决了客户的问题就是值得认可的。另外如果真要说是不是大规模敏捷框架，那么就要回归敏捷的4条价值观： 个体和互动 高于 流程和工具 可工作的软件 高于 详尽的文档 客户合作 高于合同谈判 响应变化 高于 遵循计划 不管是SAFe也好，Scrum也好，都是声称自己是敏捷的方法，那么就要遵循敏捷的价值观。如果脱离了敏捷价值观，那么就不再是敏捷方法了。 下面是微信群里大家关于SAFe的一些讨论摘抄： Ken Fang 下午9:03 SAFe 當然是符合敏捷的思想。而任何人的批評，往往才是最佳的學習與成長的素材。Michael James 的批評，啟發了另一种思維……如何誏团队不論是採用XP, Scrum或SAFe，都要能更加的 “擁抱变化”。而这也應該是XP, Scrum, SAFe, 所有敏捷咨询顧問所需面对的最主要挑戰。 Ken Fang 下午9:19 团队/組織敏捷的核心度量指標……团队/組織是否可擁抱由外部市場，外部使用者所引起的变化？！基本上，“擁抱变化” 不是个新話题，人類在这話题上已奮鬥，鑽研，爭論了半个多世紀……現在，終於在敏捷上找到了方向，但，各式的实踐仍再不断的演進;如:ZapThink。當然，各類的批评也不断的湧現。这就是走軟件这行，最吸引人的地方……永远不会只有一个標準答案, 永远不知道明天又有什么新鮮事，大師永远只活在昨天，永远只有創新，没有大師。 Julien 下午9:22 The value of SAFE is to make the management feel safe(the acronym can not be a coincidence) about the changes because they have a picture of where it is going.
2014/4/7
articleCard.readMore谈谈技术债
首先可以把技术债分3类：低级技术债、不可避免的技术债和策略技术债。 低级技术债指的是团队成员技能不足或业务不熟练、亦或是流程缺陷导致的技术债。 不可避免的技术债，通常是不可预计也不可避免的。打个比方，我们的产品使用了一个第三方的组件，在使用过程中发现该组件有缺陷，从而导致我们的产品出现故障。 策略技术债指的是组织为了快速抢占市场而有意承担的债务。 能够认识到这三类技术债后，下一步就是如何管理技术债。这里再介绍三个管理技术债的活动：管理技术债的增长，可视化技术债和偿还技术债。 管理技术债的增长：一般来说，我们会尝试用良好的技术实践来降低技术债水平，如重构，自动化测试等等。我们还需要能识别技术债的经济效果。比如为了赶工我们欠下的技术债，在经济上它到底是多少，后续会有多大的成本。 可视化技术债：可以分为业务层面和技术层面的技术债。可视化技术债的目的，是为了让所有员工都能理解技术债的影响（包括开发人员和业务人员）。业务层面的可以直接用钱来显示。而技术层面上的，可以有三种方式可视化：在缺陷跟踪系统里记录技术债；在产品backlog里记录技术债；单独一个技术债backlog。 偿还技术债：在偿还技术债时，我们要认识到不是所有技术债都需要偿还。比如即将结束的产品、一次性原型和短暂的产品是不需要偿还技术债。在开发过程中应用童子军规则（让离开时的营地比进去时更干净）。还有非常明显的一条，我们要首先偿还利息高的技术债，并且在进行开发工作时就逐步的偿还一部分技术债。 以上内容摘自《Essential Scrum》译稿第八章。
2014/4/4
articleCard.readMore排队理论的反思（1）
如果你正在某快餐厅排队等待点餐。就在这个时候，来了10个人加塞在你前面，你会怎么做？心里骂娘千百遍，还是大声呵斥并阻止这样的行为？ 在软件开发过程当中，如果发生这样的事情，比如你的团队正在进行手头的开发工作，你的老板有个“十万火急”的需求，要2天内完成。这个时候你会怎么做？忍了，还是拒绝？亦或是其他的处理办法？ 本系列文章将会从几个问题出发来描述排队的现象： 为什么会形成排队 排队有哪些后果 如何改善排队现象 为什么会形成排队 当系统的处理能力跟不上服务对象的到达率时，就会产生排队现象。（这句话也可以理解为新来的服务对象的数量要大于系统的平均处理能力）排队现象不仅仅出现在现实世界中（如开篇的例子），也出现于数字世界中。（比如软件开发，IT行业等等）那么让我们先回溯一下历史，排队理论是怎么出现的？ 早在1909年，Agner Krarup Erlan就发表了一篇关于排队理论的论文。在论文中，他研究人们打电话的方式，发展出人们需要等待多久的公式。 再次发散一下，受到美国福特汽车生产的影响，许多企业认为（包括福特）大批量的生产可以降低单件的成本，从而可以降低整辆汽车的总成本。这句话的前半部分是成立的，但是单件成本的降低，不一定会带来整车成本的降低。（具体原因后面会进行分析）现在的软件行业仍然被这种思想困扰。 后来丰田汽车独创了丰田生产系统（TPS）模式，以及时生产（Just In Time）和自动化（Jidoka）为支柱，持续改善为基础。分析TPS发现，丰田是全局考虑，从而保证生产的每个环节都得到优化，并且一旦某个环节出错立刻停止生产（避免更多的浪费）；而福特的理念，属于局部优化，每个环节都做到最优化（批量生产从而降低成本），但失去了全局的集成考虑和整体优化。 回到我们的主题上，目前行业的排队现象多是受到批量生产思想影响而造成的。如果能很好的学习丰田模式（精益）的话，也会较好的解决排队现象。 在生产行业况且存在如此多的排队，那么软件开发行业是怎么样的呢？据不完全数据统计，99%的软件开发企业都存在排队现象。这是因为在软件开发当中，排队是不可见的，并且很少会有公司对此进行衡量，那么允许排队现象的存在（并且越来越严重）便是司空见惯的了。 总结一下 造成排队的原因主要有三： 系统的处理能力达不到（跟不上）服务对象的到达率 批量生产思想的影响（单件成本下降，从而整体成本会下降） 软件开发行业的排队现象不可见 说了这么多排队，排队理论、现象；那么是否排队就一定不好，排队会有什么样的后果，以及如何优化排队呢？ 敬请期待本系列的第二篇，排队会产生哪些后果？
2014/3/31
articleCard.readMore读书笔记《极客与团队》
本书的两名作者是来自谷歌的Brian和Ben，也曾经是SVN的初创人员。本书是写给程序员看的，教你怎么交朋友，怎么影响团队中的其他人。让你在技术团队中过的更开心，变得更有效率，更加如鱼得水。本书想要帮助程序员改进理解他人，与人沟通以及与人合作的能力，从而在编写软件过程中更加有效率。 全书的核心是HRT三支柱，分别是： Humunity - 谦虚 Respect - 尊重 Trust - 信任 不论做什么事情，不论个体还是团队，都应该遵循HRT的价值观。如果团队的人际关系出了问题，那么一般来说就是HRT的某个方面出现问题。 谦虚 中国有句古话叫做“谦虚使人进步”，要知道这个世界是山外有山，人外有人。只有抱着谦虚的态度（知之为知之，不知为不知），才能赢得别人的尊重。 尊重 真心实意地关心同事。他们都是活生生的人，能力和成绩都需要得到肯定。 信任 要相信别人的能力和判断力。在适当的时候懂得放权。 在本书中，还有一个团队的良好实践，我非常喜欢，摘抄如下： - 写一份明明白白的任务宗旨，这样可以随时保持专注，知道哪些是目标，哪些不是。 - Email讨论要有礼仪。保留归档，要求新人研读，防范那些“嘈杂的少数人” - 所有历史都要有记录。包含代码历史，设计决策，重要的bug修复以及过去犯下的错误 - 有效进行协作。利用版本控制，代码改动尽可能的小，方便进行代码审查，扩大公车因子，避免出现领地感 - 修复缺陷、测试，发布要有清晰的政策和流程 - 降低新人加入时的壁垒 - 共识决策 优秀团队的沟通模式：沟通的指导原则之一就是同步沟通的时候（比如开会），人越少越好。（只有相关的人参加）而在异步沟通的时候（比如Email），涉及的听众越多越好。更重要的是，必须确保项目文档里的信息尽可能让所有人看到。 顺便作者提了一个有关开会的小提示： 只邀请一定要参加的人 开会前要决定好议程，且事先通知所有人 达成目的后立刻散会 注意别跑题 尽量把会议安排在休息时间前（比如午饭时间，下班前） 大海航行靠船长：优秀的团队必须有一名优秀的带头人（leader）。这一章介绍了作为带头人，进行管理的模式，反模式，一些小窍门以及激励措施。在这里作者使用了大量实例进行反模式的说明，非常值得学习。 如何对付害群之马：在这一章，作者的宗旨是对事不对人。发现有害团队的行为，立刻进行制止或采取行动。同时也有大量害群之马行为的举例。强烈建议浏览。 作者在最后指出，这些方式方法不仅仅局限于软件开发行业。只要和团队有关，比如社区建设等都能应用这些方法。所有这些的核心就是HRT（发音heart），还记得什么是HRT吗？ 欢迎大家一起讨论有关团队建设方面的话题。
2014/3/21
articleCard.readMore如何做好一个工作坊
刚刚过去的周日，即3月9日，王立杰老师和我一起办了一场敏捷实战工作坊。这里是一个学员的总结。回来后，我也在反思究竟什么样子的工作坊是大家想要的呢？ 我的观点是：有种、有趣、有料。（希望罗振宇同学不会告我侵权） 有种 种是种子的种，因此作为一个好的工作坊，首先要有一颗好的种子，即好的话题，好的方向。你的话题要够新颖大胆，方向要够准。这样观众才会喜欢你的工作坊。 有趣 相信大家在参加培训或工作坊的时候，不愿意听长篇大论或干巴巴的数据。我也深有同感。如果一个老师在开场5分钟内不讲一个故事，我基本会走神。接下来会睡觉看手机。所以真正好的工作坊需要时刻能抓住听众的注意力，而有趣则是关键。何为有趣呢？让我们来看看维基百科是如何定义有趣的。 Fun is the enjoyment of pleasure, particularly in leisure activities. Fun is an experience - short-term, often unexpected, informal, not cerebral and generally purposeless. 有趣是一种愉悦的享受，尤其是业余活动。有趣是一种体验——短暂的、通常是出乎意料的、不理智的或无目的的。 有料 有料，指的是有实际内容，参加的人可以真正从中有所学，有所悟。这也就达到了办工作坊的目的。比如上周日我们办的敏捷实战工作坊，就是想让大家通过一次虚拟项目真正体验一下Scrum是如何运作的。 那么办好工作坊，是不是满足“有种、有趣、有料”就够了呢？显然不是的。这只是一个前提，主要是和需要准备的内容有关，在下一期我将介绍在交付工作坊过程中需要注意哪些问题。
2014/3/10
articleCard.readMore精益看板研讨会总结－2014.02.22
2014年2月22日下午，在中关村创新研修学院迎来了第一次“精益看板”活动。本次活动的发起链接请点击这里。 本次活动主要有3部分组成： 王明兰为大家带来的话题是《大规模产品线的管理框架》。在这个话题中，明兰介绍了诺基亚从一开始的Scrum到现在的看板敏捷之路，并总结了一套基于看板的管理框架。 第二个话题是Julien为大家带来的《To be Lean or not to be?》首先Julien介绍了什么是精益，以及精益的核心。 通过消除浪费以交付价值 尊重员工 通过科学方法持续改进 关注接力棒而不是跑者 停止生产线 然后Julien介绍了什么是精益创业（核心是build, measure, and learn)，以及精益创业和精益之间的联系。最后是有关看板的介绍，以及看板是如何符合精益的核心价值。可以参考Julien的幻灯片。 最后第三部分，是一个有点复杂的看板游戏。不过这个游戏很好的模拟了现实工作中的各个场景。比如紧急任务、阻碍、改进任务、跨职能团队等等，而且还需要绘制累计流图、控制图、财务分析表等。真的是非常全面。详细的游戏介绍，可以参考网站：https://www.getkanban.com
2014/2/22
articleCard.readMore天网恢恢疏而不漏——纪念我受伤的大拇指
“就是他，就是他撞的我们” ——2014年2月15日中午，在我回家的路上，确切的说是马上进入小区大门的时候，我结结实实的撞上了一辆三轮摩的。“我的个娘亲，新车处女撞”就这么没了。如下图，我从南向西左转弯进小区，摩的从北向南直行，转弯不让直行，非常明显我应该负全部责任。 狗血第一幕：警察在现场发生的事故。 在我左转弯位置的前方有一辆警车，正在处理另一起交通事故。警察叔叔亲眼目睹我撞车全过程。撞车之后，我第一时间下车，想看一下摩的的情况以及是否有人员受伤。没想到啊没想到，摩的想要逃逸。。。怎奈摩的大叔没有想到咱是山东大汉，想当年景阳冈上武松打虎，都是何等威风。对付一个小小的摩的，那是手到擒来。嗨！哪里跑！我一下子就把摩的前轮抬起，失去了动力，它也就跑不掉了。警察叔叔关键时刻快速跑来，拔下摩的车钥匙。拿下！ 狗血第二幕：摩的司机竟然是…… 我和警察叔叔拦下摩的后，回到本文开头，一位大妈厉声怒斥：“就是他，就是他撞的我们！”什么情况啊，我刚刚拦下摩的，还没有和摩的交涉细节，就杀出一个程咬金。（该不会是趁机敲诈摩的司机吧）这时候，警察叔叔起到关键作用。他竟然判罚这次事故是主次责任（我负主要责任）。那也就是说摩的有责任啦，jcss问你们要不要私了。。。此处按下不表，回到大妈那边。不大一会儿，就出来4、5个壮小伙子，拦住摩的司机不让走。摩的司机死不承认和大妈有任何瓜葛……最后经过jcss的现场勘查鉴定（开头提到的另一起事故），我撞下的摩的司机，原来他真的是另一起事故的肇事者！ 结尾：天网恢恢疏而不漏 摩的司机怎么这么笨蛋，撞人逃跑了，还要回来？回来之后又被我撞倒！真所谓“天网恢恢疏而不漏”。 最后附上我受伤的大拇指留念（拦截摩的时所伤）。
2014/2/18
articleCard.readMore谈谈Google的OKR与其他公司KPI的不同之处
OKR是Objectives and Key Results的缩写，这套系统由英特尔公司制定，在谷歌成立不到一年的时间，被投资者约翰·都尔(John-Doerr)引入谷歌，并一直沿用至今。 那么OKR和KPI之间有什么联系和区别呢？ 1. 国内的很多绩效管理，很多时候只是做到了“考核”这一步而已，并不是完整的绩效管理体系，这是大前提。 2. OKR的思路是先制定目标，然后明确目标的结果，再对结果进行量化，最后考核完成情况。本质上和其他的绩效管理思路没有太大的不同。任何一种绩效管理，都是先有目标，对目标进行分解，量化KPI，然后考核。 3. 说说OKR和常规绩效考核的不同。 （1）.OKR实行的前提，是员工具有主观能动性、创造性，并且具有较高的职业道德素养和突出的专业技术能力。OKR体系下的目标，是由个人提出，然后由组织确定，这点与常规的KPI自上而下的方式不同。 （2）.其实目标管理法，德鲁克大师在1954年就提出来了。德鲁克1954年提出一个“目标与自我控制管理”。德鲁克认为，并不是有了工作才有了目标，而是相反，有了目标才能确定每个人的工作。不过，德鲁克的这个理论，更偏向于组织目标的统一性。 （3）.其实，任何一个公司，都有一部分员工在使用OKR思路，不过大部分员工采用的是KPI思路。区别在于： A. KPI思路是自上而下，首先确定组织目标，然后对组织目标进行分解直到个人目标，然后对个人目标进行量化。 B. 而OKR的思路是一定程度上的自下而上，个人提出目标，然后对目标进行量化。通过把大量的个人目标进行统一，汇总成公司的目标。 那么作为Google使用的OKR有哪些特点： 1. 简单：操作简单，每个被考核者的目标不超过5个，目标多了方向不清晰，重点不明确。每个目标不超过4个具体KR （具体行动）。简单就是抓住重点，容易操作； 2. 直接：每个KR都必须是能够直接完成相对应目标的；不是间接完成，更不是协助完成，最不能接收的就是可能有帮助； 3. 透明：每个单位、每个人的目标和KR，以及最终的评分都是对整个公司，甚至对每个人都是公开和透明的。一来有助于团队合作，二来有助于公平，三来是一个不错的激励手段，总是完成的不好是很丢人的咯。 具体实施OKR的关键点是什么： 1.设定目标。如何设定目标，可以参考SMART原则。 2.明确每个目标的KRs（关键结果） 3.定期回顾。每个季度做回顾。到了季度末，员工需要给自己的KRs的完成情况和完成质量打分——这个打分过程只需花费几分钟时间，分数的范围在0到1分之间，而最理想的得分是在0.6到0.7之间。如果达到1分，说明目标定得太低；如果低于0.4分，则说明可能存在问题。
2014/2/16
articleCard.readMore《如何阅读一本书》读书笔记
阅读首先应该是一种主动阅读，一种学习的态度。 根据本书的一些规则，针对《如何阅读一本书》本身，我尝试回答以下问题。 这本书的分类 实用性的书 用最简短的文字描述本书在谈些什么 阅读的层次，以及针对不同类型的书的阅读方法 作者要解决的问题是什么 提高阅读水平 阅读分为4个层次（每个后面的层次都包含前一个层次） 基础阅读 检视阅读（可以理解为粗读、或快速阅读，虽然不是完全一致的含义） 分析阅读（精读，吃透一本书） 主题阅读（某个相关主题的一系列书记的阅读） 基础阅读还可以分为4个阶段： 阅读准备阶段：从出生到6、7岁。 学习读一些简单读物（看图识字，几百字的书籍）。 快速建立词汇的能力，从上下文所提供的线索，“揭发”不熟悉的字眼。 精炼和增进前面的技巧。 检视阅读分为2个阶段： 有系统的粗读——帮助读者分析在这个阶段一定要回答的问题。准备了解书本的架构。 粗浅的阅读——帮助读者在分析阅读中进入第二个阶段。 分析阅读，本书做了大量的介绍。分为3个阶段，15个问题。 找出一本书在谈论什么 按照书的种类和主题进行分类 使用最简短的文字说明整本书在谈些什么 将主要部分按顺序和关联性列举出来。将全书的大纲和各个部分的大纲列出来。 确定作者想要解决的问题 了解一本书的内容 找出书中的关键字 由最重要的句子中，抓住作者的重要主旨 知道作者的论述是什么，从内容中找出相关的句子，再重新架构出来。 确定作者已经解决了哪些问题，还有哪些是没解决的。再判断哪些是作者知道他没解决的。 评论一本书 除非你已经完成大纲架构，也能诠释整本书，否则不要轻易批评。 不要争强好胜，非辩到底不可 在说出评论之前，你要能证明自己区别的出真正的知识和个人观点的不同 证明作者的知识不足 证明作者的知识错误 证明作者不合逻辑 证明作者的分析和理由是不完整的 主题阅读： 准备阶段：针对要研究的主题，设计一个试验性的书单。 浏览书单上所有的书，确定哪些和主题相关。 浏览所有确定的书籍，找出相关章节 根据主题创造出一套中立的词汇 建立一个中立的主旨 界定主要和次要议题 分析这些讨论
2014/2/13
articleCard.readMore敏捷转型中管理层的认同和支持
敏捷转型是一种涉及管理层的组织级变革。我们常说管理层的认同对于敏捷是否能取得成功很关键，缺少管理层的支持，敏捷转型就可能会遇到巨大障碍。公司中管理层支持敏捷有很多不同的方法。 Arijit Sarbagna在《规范的Scrum（prescriptive Scrum）》一文中讨论了在敏捷转型过程中管理层的认同和支持的重要性： 假设我们正在以敏捷方式开发项目，最初采纳敏捷不是自上而下的，而是徒劳的“自下而上”。在这种情况下中，很可能我们就会错失了“管理层认同”这个关键因素。缺乏管理层的支持，打造自组织团队的良好意图很可能会走进死胡同。作为ScrumMaster或者敏捷教练，我们需要花费大部分的精力来说服管理层（或者客户），而不是实际上的指导团队。 根据Arijit的观点，对经理而言支持自组织团队非常困难： （……）管理团队遭遇决策的困境，在团队成为“自组织团队”过程中应该留有多少回旋余地。这很搞笑方，我们不得不跟管理层解释敏捷是如何工作的，为了使敏捷有效，管理层应该相信敏捷。有时我们必须要提醒管理层，如果我们不信赖员工，即使瀑布式开发也不会成功。信任是成功的支柱，围绕着信任我们补充了工程实践。 Arijit建议经理不应该强制实施Scrum： 但是，如果我们正在处于规范化Scrum困境的话，比如很可能管理层会指导团队，敏捷应该怎么做（或不应该怎么做）——这些人可能从未实施过敏捷而只有理论知识——那么这只会让事情变得更糟，或者变成“失败的故事” 。 相反，Arijit建议“宣扬和鼓励理解敏捷的人，从而拥抱实践”。 Zvonimir Križ写过一篇文章《亲爱的经理，我们已经敏捷了（dear management, we’re already agile）》，文中质疑缺少管理层的支持是否是采纳敏捷的真正障碍。这个问题可以理解为，当关注于实践而不是敏捷原则的时候，实施敏捷的唯一方法就是自上而下： 从诸如Scrum之类的实践直接开始敏捷可能使人们相信，敏捷“旅程”需要深层的组织变革。当然组织变革需要管理层的支持。另一个更有趣的原因是瀑布式开发本身。为了更加精确，瀑布式开发需要大量的前期规划（upfront planning）。这也是我们大脑中的一种思维惯性，为了成功，所有事情——包括敏捷转型——都应该详细规划。此外，管理层需要如此大量的前期规划和重大决策。 Arijit建议敏捷转型还可以采用自下而上的方法： 有时候人们忘记了自下而上的敏捷转型是合理的。 每个人应该都知道采用敏捷原则不需要依赖管理层。（……）你可以现在就开始。不需要任何理由！ 我们曾采访过Jeff Sutherland，他在《敏捷做了对的事，但方向却错误（agile done right and agile gone wrong）》一文中提到了领导力和团队。Jeff在Google Plus上分享了这次采访，他提到管理层可以采取如下做法来支持敏捷： 这和管理层的认同无关。而是与敏捷管理层如何敏捷、领导以及展示变化相关。在某些大型公司内，会有由高级管理层组成的Scrum团队。他们不会赋予团队执行Scrum的权利，而是自己也在执行Scrum，并且希望团队和他们一样执行Scrum。 在敏捷转型过程中，中层管理者该如何支持呢？Em Campbell-Pretty写了一篇文章描述这个问题《对敏捷教练与中层管理者沟通的建议（advice for agile coaches on “dealing with” middle management）》。文中说明了为什么管理层的认同如此重要： 和开发团队一起工作时，中层管理的认同非常关键。对于敏捷转型工作，中层管理者可以是良好的动力也可以是克星。如果团队认识到管理层不支持敏捷，那么在试验和冒失败风险的时候他们还会觉得安全吗？我曾见过有些组织尝试敏捷转型，而管理层仍然是传统思维。对于团队而言，这将是毁灭性的问题，如果团队相信敏捷的价值观如透明性，那么他们就会因为暴露事实而受到管理层的谴责。 针对如何解决来自中层管理者的阻力，Em Campbell-Pretty给出了如下建议： 有些管理者慢慢发现敏捷对他们有威胁。实施敏捷很可能意味着改变，没有人喜欢改变。在这种情况下，或许可以考虑一下Dennis Stevens和Mike Cottmeyer的建议（Agile 2013大会上的“不要谈论敏捷”），而不是迫使顽固的经理实施敏捷。相反，我们应该关注于业务目标，以及如何帮助管理层达到他们的目标或减轻他们的痛苦。 通常组织里的中层管理者也同样处于困境。根据Em的文章，敏捷教练应该负起责任，寻找方法和中层管理者一起工作并支持他们的工作： 中层管理者其实并不容易，实质上他们就像“三明治里的肉”，处于组织的高级管理者和普通业务人员之间。中层管理者的责任大于权利的情况司空见惯。这可能非常令人沮丧，并且让我怀疑命令与控制管理风格的盛行，是否是大型的官僚组织里中层管理者丧失权利的直接后果。中层管理者的注意力从组织繁文缛节的沮丧转移到改善员工的生活上，对于管理者和团队都是一种回报。不要忘记，中层管理者和其他人一样，倾向于能为我带来什么好处（WIFM——what’s in to for me）。中层管理者必须明白敏捷会如何帮助他们获得成功。
2014/2/11
articleCard.readMore团队绩效指标
几乎我教过的每堂课或辅导过的每个组织都有下面这个问题：“我应该用什么指标来确定团队是否运行良好？”我可以理解这个问题的背景是，大多数人想问开发团队的绩效，而不是整个Scrum团队（包含产品负责人、ScrumMaster和开发团队），也不是整个组织的绩效。 有时候我也想知道开发团队做得怎么样，所以我会在本文阐述这个问题。但是，对我来说这个问题和下面两个问题几乎不相关：“作为敏捷组织我们做的怎么样？”或“Scrum团队做的怎么样？”。这些问题的答案可以使我们在经济相关性和可操作性层面有更深入的理解。在组织层面我想了解我们是否高效地交付客户期望的价值。为了理解这一点，我会采用如下指标： 无用功（Idle work） 和闲散员工（idle workers） — 衡量工作流受阻的时间和频率（而不是衡量员工有多忙）。 交付可工作和验证过的产品—如果我们交付的产品客户不用的话，那么按时及在预算内交付就没有任何意义。 作为组织我们的学习速度—采用如innovation accounting （精益创业的概念）的指标来评估我们学习的速度，该速度可以作为汇聚业务价值结果的进度指标。 在组织层面之下我会关注整个Scrum团队。3个角色一起交付正确的客户价值并快速较好的完成。所以我更喜欢下面这个指标“每个迭代Scrum团队都在交付较好的价值吗？”(more on this shortly)。但是如果我们只想衡量开发团队怎么办（以下简称“团队”）？或许我们想知道给团队分配某人是否是正确的选择。如果开发团队会长久在一起，那么我们就想知道团队的绩效。下面我推荐几个指标（排除使用开发速率）： 几乎每次团队都能完成迭代目标 产品负责人相信团队交付较好的经济价值 团队以可持续的节奏工作 团队的T型技能（一专多能） 团队的学习速度 开发速率（不建议使用这个指标） 许多人认为，开发速率是一种衡量团队绩效显而易见的方法。不幸的是，开发速率应该只是一种计划工具（如发布计划）和团队诊断指标（如流程改进工作）。速率不应该作为一个绩效指标来判断生产效率。因为速率太容易做假了。如果团队成员知道速率作为绩效指标的话，他们就会在每个迭代随意增大产品backlog条目的大小（故事点通胀），或者为了完成更多的故事而偷工减料（注：即牺牲质量或增加技术债）。在《Essential Scrum》一书中，详细描述了什么是速率，应该如何使用速率以及应用速率的误区。在本文中，我不会把速率作为团队绩效的指标。 实现迭代目标 排除了开发速率，我们应该用什么来衡量团队绩效呢？一个指标是团队以什么频率实现迭代目标。作为Scrum原则，每个迭代应该有一个目标（就像可执行的汇总说明），这个目标是团队一起承诺要实现的。每个迭代团队尽最大努力实现目标。我宁愿每个迭代团队没有完成目标，因为这可能是团队习惯性无法完成承诺的迹象。有时候，团队为了达到目标做出了相当的努力，但最终由于正当的原因（比如目标的弹性比较大）而没能完成。这个现象更好地表明了团队应该在合理的限度内进行工作。 交付价值 检查和平衡团队“虚报估算”的一种简单而恰当的方法是，咨询产品负责人是否每个迭代都能获得良好的价值。多数的迭代都是固定成本的——我们知道团队人员和迭代的时间长度都是固定的，因此每个迭代的成本也就是固定的。假设每个迭代的成本是2万美元，对产品负责人而言一个重要的问题就是，“你觉得每个迭代能至少获得2万美元的价值吗？”好的产品负责人会知道答案。如果产品负责人说，“没错，我很满意团队正在交付的价值，”那么这就是团队良好绩效的表现。再说明一点，产品负责人对迭代级别和发布级别的经济性是总体负责的。因此，如果产品负责人草率地花了2万美元，让团队只交付1万美元的价值的话，那么这个产品负责人就是不负责任。总之，交付良好价值是整个Scrum团队（产品负责人，ScrumMaster和开发团队）的责任，当评估开发团队时可以考虑这个指标。 可持续的节奏工作 我还想要知道是否每个迭代团队都能以可持续地节奏交付良好的价值。我们都见过为了交付迭代目标而一周工作80小时的情况。对于这个情况的第一个反应可能是，“看看，多么棒的团队，他们为了完成工作愿意加班！” 常常一个迭代中为了完成目标，工作更长时间切更努力一点是必须的。因为总是有一些难以预料的事情。然而，人们不能长时间以这种节奏工作，所以一周工作80小时的团队不会长久的成为“优秀团队”，很快他们就变成“疲惫不堪的团队”了。因此，第三个衡量高绩效团队的指标是，每个迭代都以可持续的节奏交付良好的价值。 扩展T型技能 另一个高绩效团队的指标是：“团队成员有没有更进一步扩展T型技能？”T型技能职这样一个比喻，用来描述一个人在专业领域有深入的垂直技能，同时其它相关领域拥有广泛的（没必要那么深入）水平技能。由T型技能的人组成的团队更不易受到工作变化的影响，因为可能多个团队成员都可以工作在该领域上，所以在有大量工作时团队可以蜂拥式的集中工作。我认为团队成员的T型技能是团队健康和高效能的重要指标。 快速频繁地学习能力 最后，需要评估团队的学习能力。尤其是，我想评估团队完成学习循环的能力：假设、构建、反馈、检视和调整。高效能团队总是快速验证重要的假设，并根据结果而采取行动。高效能团队以最大化学习重要细节能力的方式组织工作，因此他们可以根据学习进行调整。考虑到快速而频繁学习的重要性，我会在组织层面和团队层面都采用这个指标。快速学习重要信息并尽最大的努力工作，超越那些学习慢的团队，就像团队那样，学习最快的组织常常痛击他们的对手。 总结 总结一下，当衡量绩效的时候，首先考虑的是较高层面如组织、Scrum团队级别的。当评估开发团队的时候，不要采用速率。相反，考虑之前我提到的一套多维的指标会获得团队绩效的全面情况。最后一点意见。以我的经验，组织里好的经理实际上不需要任何官方团队绩效的指标。这样的经理和团队保持紧密联系，细心观察发生的一切。咨询一个好的经理关于团队绩效，包含强项和弱点，这个经理都会马上给出全面的答案。 英语原文请点击链接
2014/2/9
articleCard.readMore读《仆人领导时大鲲》有感
人生的5F 很早以前，时大鲲公开表示把自己的人生次序用5个F来排列（按照重要顺序从上到下）： Faith - 理念或信仰 Family - 家庭 Firm - 公司 Fun - 娱乐 Future - 未来 点评：人生在世，时间非常短，做事就要有一个先后，主次顺序。否则东做一点，西做一点，到头来就是大黑傻子掰苞米——两手空。时大鲲的这个5F就完美的总结了成功人士看待事情的优先级。信仰>家庭>公司>娱乐>未来。 企业的3P和3I 全世界的公司，你抽茧拨丝后无外乎有三个核心： People - 人员 - 人员需要激励(Inspire) Process - 流程 - 流程需要整合(Integrate) Product - 产品 - 产品需要创新(Innovate) 点评：太精辟了！3P和3I，公司的事情全都包括了。人、流程和产品，如果哪一个做不好，公司都很危险。
2014/1/26
articleCard.readMore一个ScrumMaster的自白
你刚刚走出CSM课程，全身充满了Scrum知识和对于软件开发实践的信心。你迫不及待地要分享新的世界观，以及告诉别人敏捷是如何帮助团队的。但是，在第一个敏捷项目中，你就碰到阻力、反对，甚至更糟糕的，Scrum-But（注：伪Scrum，如每周只有2次站会；流于形式而没有领会Scrum的精髓）。ScrumMaster要做什么呢？ 不要放弃希望！你肯定不是第一个碰到这些问题的ScrumMaster，也不会是唯一一个。我以前在项目中碰到过这些情况，并且我很愿意分享给大家。学会克服这些问题，将会使你成为一个优秀的ScrumMaster，也能帮助团队达到高效能。 1. 缓慢开始。 敏捷（Scrum）对于多数团队、公司（尤其是大公司）和文化而言是一个巨大的挑战。仅仅因为你相信Scrum和敏捷的奇迹，这不能保证其他人也有同样的感觉。先尝试实现那些马上有结果的事情（先摘好摘的果实）。如果你所在的组织允许你挑选团队成员的话，那么太棒了。但如果不行的话，比如给你一个组建好的团队，来进行Scrum转型可能会困难一些。因此缓慢开始，先解决团队的问题，比如构建信任……参见《克服团队协作的五种障碍》 2. 有耐心。 我必须强调这一点。团队在第一天、甚至是第一个迭代不会形成自组织。开始的时候，团队很可能不会每天更新敏捷工具（白板等）。每日站会可能超过15分钟或者大家偏离了3个问题的形式。尝试耐心一点，辅导团队让他们时刻记住Scrum的原则。团队会以自己的方式记住这些。团队需要时间学会一起工作，相信彼此，相信流程，信任你（ScrumMaster）。 3. 坚持Scrum。 当团队开始偏离（迫于管理层的要求）Scrum实践时，你就会看到额外的不必要的复杂性。你的工作是在Scrum基础知识方面辅导团队，这些已经被证明是成功的，你要保护团队不受外界的打扰。尽你最大的努力帮助团队，避免修改Scrum。如果团队和管理层坚持要修改Scrum的话…… 那么 4. 多问“为什么？” 这个简单的词可以产生事情是如何完成的现实。通常，偏离Scrum的原因不是实质的问题。通过问为什么，可以找到根本原因并开始解决真正的问题。如果没有得到很好的答案，那么继续问；有时候需要多问几次为什么才能找到原因。（参考精益里面的5个为什么） 5. 说明、解释。 当团队知道你做这些事情的原因，或要求他们这么做的原因后，团队可能更愿意接受改变。通过确认让团队理解为什么要这么做，团队会感到更有自主权，因为这样团队有一个清晰的目标。 6. 授权团队和你自己。 通过授权团队，团队能够获得更多的自主权。这是自组织的第一步。通过授权你自己，你能展示和鼓励团队遵循Scrum。团队通过行动而学习；当你用敏捷的原则行事时，团队都可以注意到。自我授权会让你看起来更加自信，也会成为一个优秀的ScrumMaster。 7. 寻求帮助。 面对现实吧，CSM课程不会告诉你如何面对所有的情况。团队、利益相关人和管理层之间的关系是非常复杂的。不要试图一个人解决所有的问题。团队一起来面对问题，并移除障碍，当然你要展示出识别问题的能力。如果等太久而没有寻求帮助的话，那么团队就危险了——这是ScrumMaster要避免的事情。 8. 寻求反馈并给出反馈。 这点要回到“检视和调整（Inspect and Adapt）”原则。反馈不必等到迭代结束的时候，在回顾会议上提出。如果你发现有可以改进的地方，用建设性的方式提出来，因此你可以很早就帮忙改正问题。同时也要向团队要反馈。欢迎团队提出反馈意见，这样也创建了一个开放的文化和持续改进的环境。 9. 信任团队。 我已经多次提到信任，但信任太重要了我想单独讨论一下。信任即使不是团队必须的最重要的元素，也是最重要的元素之一。团队成员需要相信你，了解你信任团队，并且彼此之间相互信任。团队相信他们可以交付良好的软件，即使碰到了上述的障碍。团队相信走在正确的道路上，会开发出正确的软件，也会最终成功。最重要的是，团队要相信失败不是最可怕的；他们要相信可以做的更好，并且不会犯同样的错误。 10. 习惯不自在的事情。Get comfortable being uncomfortable Scrum一开始会让人感到不自在。情况不会马上好转：团队的开发速率一团糟，需要花一点时间改变团队的动态，并且管理层不总是支持敏捷。作为ScrumMaster，你会碰到很多的未知，这些都很不容易。此外，当团队开始自组织的时候，团队需要更多的自主权。尤其你以前是项目经理的话，这会让你更抓狂。 另外，拒绝人也是不自在的事情。你要习惯告诉团队之外的人“可以还是不可以参与”。你需要给产品负责人提出指导，如何在产品backlog里增加用户故事，而不是在当前迭代里面修改产品backlog。你需要拒绝改变Scrum流程，并且你需要组织伪敏捷的方法。保护团队的方法，就是学会说“不”。 回头看看所有这些战胜不自在的方法。相信自己，相信Scrum实践，信任团队会持续在正确的方向上： 努力争取高效能并交付商业价值。 原文链接：https://www.scrumalliance.org/community/articles/2013/january/confessions-of-a-new-scrummaster 注：认真理解并做好上述的方法后，你也可以成为一个认证的ScrumMaster （CSM）
2014/1/25
articleCard.readMoreGROW模型
GROW模型是一种解决问题或设定目标的方法，最早起源于1980年的英国。下面介绍一下什么是GROW模型： Goal - 目标。我最终要达到一个什么结果，可以让客户对自己有一个清晰的规划。 Reality - 现实。当前的现实情况是怎样的，存在什么问题、挑战，以及和目标之间的差距。 Obstacles - 障碍。从现实到目标之间的障碍是什么。如果没有障碍，客户就已经实现目标了。 or Options - 方案。一旦识别出障碍，就需要找出如何移除障碍。这就是方案。 Way Forward - 前进的道路。形成方案之后，就需要具体的行动计划来达成目标。这就是前进的道路。 下面举一个例子 比如我想减肥（作为胖子，泪奔……）。因此我定了一个目标是“在1年之内体重减到70公斤”。下一步找出现实情况（当前体重为79公斤，继续泪奔）。接着我们需要一些开放问题，来引导自己识别障碍并形成方案。 曾经有过减肥吗——如果有减肥前后有什么区别？ 减肥后反弹是什么心情？ 这次想要有些什么改变来保持体形？ 假如我能很好的反思这几个问题，就会发现在减肥的时候，哪些行为会阻碍减肥、哪些方法有效。接着会根据这些发现来寻找解决方案，（比如减肥菜谱，增加运动）一旦我找出这些，就会建立一套可行的行动计划。毫无疑问要对自己做出承诺，每天需要坚持某个减肥菜谱，每周进行多少运动。 GROW模型里面有2个非常关键的元素：1. 设定目标。我们想要达到什么，时刻记着自己的方向。2. 识别障碍。找出现在的情况，并识别出有哪些因素阻碍达到目标。 《网球的内心游戏》作者Tim Gallwey将GROW模型在学习领域做了进一步的推广与应用（不仅仅限于学习打网球）。 在多数学习环境下，学习者很少会关注正在发生的事情。如果学习者能够更加关注当前的事情，而不是“应该做什么”或“怎么做对”的话，那么他们将取得更大的进步。 当学习者关注于当下的时候，他们就会察觉如何可以获得成功。 如果学习者关注观众、奖金或耍酷——这些毫无疑问会妨碍专注力，从而导致失败。学习过程中越少的打扰，通常来说进步会越大。
2014/1/23
articleCard.readMore卡诺模型-产品需求的认识
卡诺模型是有关需求认知的一个很重要的模型。1984年日本人Noriaki Kano博士提出的。在这个模型里把需求分为4类。 亮点（attraction）需求 线性（linear）需求 基础（fundamental）需求 无差异（indifference）需求 模型是一个二维图表，横坐标是产品功能（左边是不需要实现，右边是必须实现），纵坐标是客户满意度（上边是客户非常满意，下面是客户不满意）。 一个产品的需求无外乎包含以上4类需求。我们需要知道这4类需求的特点，来区别对待才能最优我们的产品。 亮点需求 对于一个产品，如果没有亮点需求，那么就很难出类拔萃，赢得大部分的用户。这类需求有点类似锦上添花（注意不是画蛇添足噢），如果没有实现，不会有太大的问题，一旦实现了这类需求，产品能让人们眼前一亮。现在公司都提倡创新，也是这个原因。从模型上我们不难看出，亮点需求对客户满意度的影响最大，但不是必须实现的。 线性需求 这类需求包括可用性、易用性、可扩展性。线性需求的特点是完成的越多，客户越满意。在产品中大量的功能是这一类，因此我们需要尽可能多的实现线性需求。 基础需求 基础需求是产品的基石，也可以说是基本法则。比如安卓应用的图标或者默认操作，如果擅自修改（尤其是逆天不符合用户操作习惯的改变），就属于破坏了用户的基础需求。从卡诺模型上可以看出，这类需求的特点是必须实现，但是不会对客户满意度有太多贡献。相反如果没有实现这类需求，客户肯定不满意。 无差异需求 无差异需求可以看做是可有可无。根据注明的二八法则，可以先不实现这类需求。
2014/1/21
articleCard.readMoreScrum抛球游戏介绍
游戏规则 一组或者多组都可以（每组建议5-9人——你懂得） 从哪个人开始，到那个人结束 不允许把球传给相邻的人 球必须有滞空时间 所有人都参加 每个迭代2分钟 迭代后有1分钟做回顾和下一迭代的估算 一共5个迭代（可以酌情删减） 游戏手册 介绍游戏（2分钟） 介绍游戏规则（2分钟） 团队准备时间（2分钟） 估算能传递几个球 开始第1个迭代 回顾和下一个迭代的估算（1分钟） 重复4次 总结（15分钟） 计分用的表格 总结的要点 在游戏里发生了哪些事情？ 哪个迭代是最好的？为什么？ 哪个地方能体现出Scrum工作流的好处？ 洞察（Insight） Scrum工作流=PDCA（戴明环） 系统都会有一个固有速度（类似于系统有上限、瓶颈） 只有挑战是可行的时候，才会有工作流 游戏规则的例子 游戏手册的例子 戴明环 我在QCon 2013北京上带领大家做的抛球游戏。 抛球游戏的创始人链接bor!sgloger。
2014/1/20
articleCard.readMore总结 - Agile1001公开课 第三期【北京】敏捷需求捕获By用户故事
2014.1.19 王立杰老师为大家带来了一场敏捷需求的公开课（蛇年的最后一场）。这次非常感谢联众游戏为我们提供场地赞助。（如有企业或个人能提供场地赞助，请联系我或王立杰老师） 会后的合影： 关于用户故事的3C【DanielTeng扩充为5C】和INVEST原则，也可以参考我之前总结的一篇博文。 会后大家对于这次公开课的反馈： 王x 17:32 谢谢您王老师！辛苦了[握手] Arthur 17:34 王老师讲得好！ Arthur 18:02 提问: 第一排的那个儒雅风度的是谁？ 回答: 王老师 Arthur 18:03 再提问: 后面那个短发、低调、内敛、总在思考的是？ 回答: 莫非你说的是@伍斌_Ben 老师？ 剑波 18:06 谢谢王老师这么精彩的讲座，我看将到最后您也特别累了，感谢老师的付出，您回去也好好休息吧[微笑] sherry 19:20 谢谢王老师精彩的课程 安静的发狂者 19:37 谢谢王老师！又学到不少东西 伍斌_Ben 20:30 @ArthurGuo 说说王老师今天的课程中，您最喜欢哪块内容吧。我个人最喜欢开头的视频、希望是真的和必须接受的三件事、三个C、用户故事的重心是交谈、四类用户、persona、估算故事点的练习。 Light Cavalry 20:33 我最喜欢12只小动物的那部分 婳儿 20:38 开头视频与必须接受的三件事 ArthurGuo 20:45 最喜欢: 四类用户、估算故事点 ArthurGuo 20:46 三件事、三个C这些在目前公司的非典型瀑布式开发里也实践过，当然不同 谢x 23:44 以下是根据王立杰老师分享的内容及课堂上思考总结的笔记，与大家分享： 影片中关于需求的问题（记的不太清楚了）： 备注：思考这样的问题的时候，大家可以从PMP的知识领域、产品使用角色（身份）、产品设计过程几个方面来思考，这样比较全面一些，然后找出关键的问题点及解决方案。 1、目标不够清晰 2、PO职责为定位明确 3、沟通传达不够顺畅 4、领导意识决定产品方向 5、范围、周期未能有一个相对的定义或者限制 6、迭代周期过长 7、未能定期向用户演示产品 。。。 -正文———————— 一、用户故事 1、用户故事：用户故事描述了对用户、系统或软件购买者有价值的功能 2、用户故事三要素：角色，功能，价值 3、用户故事样例：作为一个<角色>, 我想要<活动>, 以便于<商业价值>(As a , I want to , so that .
2014/1/19
articleCard.readMore敏捷软件开发中的版本规划
如上图，开始之前我们假设产品backlog做过第一次梳理，并且总的故事点为127. 0. 在迭代开始之前，需要有一个产品backlog，并且其中顶部的一些故事是相对更详细的。 1. 产品backlog需要符合INVEST标准（参见我的一篇博客）。为了达到这个标准，需要产品负责人（PO）和团队一起（早期有可能是团队代表或核心人）对产品backlog进行优先级排序，估算（有故事点估算、团队估算、三角估算等方法）等梳理工作。 2. 假设我们有一个产品backlog如附件所示，每个sprint为3周，第一个sprint团队计划完成21个故事点，基于以上假设，这个项目需要6个sprint完成，即6x3=18周时间 3. 当第一个sprint结束的时候，很不幸，团队只完成了14个故事点。那么需要基于这个事实，对于发布计划进行调整。需要10个sprint完成，即10x3=30周时间 4. 如果第二个sprint完成了18个故事点，则基于第一个和第二个sprint的数据，发布计划调整为8个sprint，即8x3=24周。此时，由于有了2个sprint的数据，我们可以对发布计划的承诺是在24周（最好的情况下）~30周（最差的情况下）之间。 5. 如果第三个sprint完成了20个故事点，则基于前三个sprint数据，发布计划调整为7个sprint，即7x3=21周。此时，由于有了3个sprint的数据，我们可以对发布计划的承诺是在21周（最好的情况下）~30周（最差的情况下）之间。 以此类推，一般来说，我们都是在3个迭代之后，对项目的发布计划做出承诺的。 \================================================================ 欢迎大家提出其他不同的版本规划方法，或者建议。谢谢！ -———————————————————————- 微信公众号: 敏捷那些事儿（agileplus） Agile1001公开课，每月一次，旨在推广和传播敏捷开发思想和Scrum，希望更多的开发者受益。欢迎关注。课程信息会定期发布，敬请关注。公开课汇总链接。
2014/1/19
articleCard.readMore企业的主管领导们，你们准备好敏捷了吗？
主管领导经常宣扬敏捷，但他们真正了解什么是敏捷吗？当然，敏捷增加了协作，提高了透明度和响应变化的能力。谁不喜欢呢？主管们所了解的是，敏捷转型只影响Scrum团队。下面让我们看看对于组织而言敏捷是什么： CIO - Chief Information Officer 传统的资源模式受到冲击。Scrum需要团队奉献精神，构建高效能团队和可靠的开发节奏（速率）。为了支持这个观点，你需要确保有价值的工作稳定产出。这需要真正的协作。 基础架构需要支持持续集成和频繁发布。开发、运维模式（dev ops），这是一种很好的方式。 敏捷转型可能需要几年时间，因此Scrum团队最大的挑战是瀑布式接口。Scrum团队快速前进并交付需求中更大程度上的不确定性，对瀑布式组织而言这意味着不熟悉的领域。接口协调就应运而生。 HR - Human Resources 需要定义新的角色和职业生涯：ScrumMasters，产品负责人，教练，和敏捷推动者。 _绩效评审_流程也受到冲击，奖励的是团队成功而不是个人成就。 有些组织通过重组或者管理层的扁平化，来引发文化的变革和授权团队。HR也不要是敏捷转型的一份子。 CFO - Chief Financial Officer 开始敏捷之后，经费从项目转变到团队经费。这个例子中预算就简化了。财务领导需要知道的是_范围不确定性_的尺度。这需要相信，团队和产品负责人会做出正确的决策。 组织开始关注业务价值而不是节约成本。从没听过Google吹嘘在员工身上省了多少钱；但听到的都是他们的创新和优秀的精英。 下一步，不要忘记为敏捷的开销留出预算：培训，教练，工具。 对财务领导还有一点是：需要为研发类型或创新实验室类型工作留出预算，团队需要寻找经费来验证一个想法。这不是对每个团队都适合的，但肯定适合新兴产品。财务的敏捷性会帮助整个敏捷转型。 COO/CMO/CEO - Chief Operating Officer/Chief Marketing Officer/Chief Executive Officer 敏捷之后业务人员的参与水平显著提高了。产品负责人不仅需要是专职的，还需要知识渊博以及授权他们做出产品决策。换句话说，业务的角色从项目经理层面转变为真正的产品所有权。企业需要一个清晰的愿景和创新推动力来支持产品负责人。成功的产品负责人真正只需做好2件事：向组织看起和权衡。设定“正确的”产品负责人会让项目获得极大成功。 项目管理办公室会发生文化改变，授权团队，或影响现有的审核流程。跟踪敏捷项目的指标是不同的，更关注于价值而不是生产效率或成本。新的标准和组织结构会慢慢浮现，比如Scrum of Scrums。PMO通常在开始大规模敏捷后才收到冲击。 物业也会被团队坐一起的需求所影响。如果没有足够的协作空间，Scrum团队就会占用会议室。 原文链接：https://www.scrumalliance.org/community/articles/2014/january/is-your-leadership-ready-for-agile
2014/1/16
articleCard.readMoreAgile1001公开课 第三期【北京】敏捷需求捕获By用户故事
Agile1001第三期公开课，再次迅速降临北京！感兴趣的同学请于后台回复报名 报名格式： 中文姓名、手机、公司 题目：【实战工作坊】敏捷需求捕获By用户故事 地点：望京附近，近地铁15号线出站口，为防止空降，具体地址另行通知。 内容：据Standish Group分析，在项目失败的原因中，有近7成是跟需求相关的。如何在敏捷的背景下有效的分析、捕获需求，是实施敏捷软件开发的第一要素。本工作坊试图通过理论讲解加上实战演练，让听众掌握如何通过用户故事(User Story)来分析、描述、估算一个需求，进而管理多个需求。 本工作坊同时覆盖如何区分用户角色，如何描述一个用户角色，如何做敏捷估算，如何划分需求优先级，如何做发布规划等进阶内容。 时间：2014年1月19日下午2:00 - 5:30 讲师：王立杰，因著有《敏捷无敌》，江湖人称“无敌哥”，多年软件研发与敏捷实施经验，曾为阿朗、爱立信、诺基亚、VMWare、E人E本、百度等多家公司做过各种敏捷培训或咨询；曾经在“2011 Scrum Gathering，“2011 AgileChina敏捷中国”等大会做过多次演讲；曾在《程序员》杂志上发表多篇敏捷相关文章，是敏捷之旅的志愿组织者，Agile1001公开的发起者。
2014/1/15
articleCard.readMore回顾会议墙——改进回顾会议结果的一种工具
_译者注：回顾会议是敏捷的核心，在敏捷原则最后一条中提到“团队定期地反思如何能提高成效，并依此调整自身的举止表现。” 对于团队如此，个人何尝不是呢。作为一个上进的人，需要时刻反思如何改进自己，调整自己的行为，向着自己的目标前进_。 回顾会议变得很无聊，或者只产生几点改进意见、做的好的地方，这是很普遍的。下面介绍一个对我的团队很有效的方法。这个方法不是说比其他方法更好。只是为回顾会议提供一个新的尝试。 首先，先说明一下为什么我想改进回顾会议。全组人（除了PO，通常是代表客户的）坐在一起，比较随意的开始提出一些想法，在这个sprint中哪些事情做得好（正面的）以及哪些地方做得不好（负面的）。所有人说完后，我们开始为每个负面因素至少制定一个行动计划，并指定一个人负责。一旦行动定好了，会议就结束了。 这看起来就是一次普通的回顾会议。不好也不坏。但是，不难找出其中的一些缺点： 人们通常忘记了在sprint中哪里做的好，或哪里做的不好。让人们在2个小时内想起一个sprint内所有事情，这是不现实的。 有些人不愿意当面提出问题。因此回顾会议上他们压根不说话。 团队创建的行动计划，但是如何跟踪，以及团队如何能想起来这些行动？ 为了解决这3个问题，我们创建了一个回顾会议墙。墙上有3列：正面（Positive），负面（Negative）和行动（Actions）。如下图所示。 在正面（positive）一列，团队成员可以在任何时间粘贴他认为好的事情。不一定要署名。类似的，在负面（negative）一列，团队成员说明从他的角度看哪些做的不好。行动（actions）一列贴着所有未完成的行动。行动卡片包含描述、何时创建的、以及谁负责跟进。一旦行动完成了，负责人在卡片上写明完成日期。 除了这3列，还有2个格子记录了上2个sprint中的行动完成百分比（已完成数/总行动数）。因此团队可以很清楚的知道他们是否改进了。重要的是：任何指标，都需要中肯的分析，而不能简单的认为它好或不好。 几个sprint之后，我们发现正面和负面问题的数量和质量都得到改善。如果你决定采用这个方法，请记住以下要点： 板（或者墙）是每个人都很容易看到的地方，这样团队每天很容易就会看到进展。 一开始，要告诉每个人我们的目的是什么。比如，在回顾会议之前，每人必须提出至少一个正面和负面的意见。这好像有点强迫，但这样可以告诉团队如何形成习惯。 树立榜样。一旦你发现团队中有好的或不好的地方，立刻在墙上贴一个便签。发现了问题之后，马上贴上去，这很重要。 https://www.scrumalliance.org/community/articles/2014/january/retrospective-wall-board
2014/1/13
articleCard.readMore总结 - Agile1001 公开课 第一期 Scrum中的角色
感谢Shining的美图。非常感谢各位热衷于敏捷开发的朋友参加公开课。 大家的反馈： huiminer 18:06 感谢Bob，王老师以及大家的分享哈～ 范x 18:07 感恩大家 闫x 18:25 今天收获还是很大的，非常感谢立杰老师百忙之中为大家联系的场地以及Bob精彩的讲课。看到大家非常投入的讨论敏捷，感觉很象个大家庭，个人有个小提议，我们以后时机成熟时可以成立个敏捷之家的论坛，这样大家也可以平时把问题提出来，共同探讨交流，再定期组织面对面会议，因为北京太大了，毕竟大家东南西北聚一起一次也很不容易。 闫x 18:26 今天收获还是很大的，非常感谢立杰老师百忙之中为大家联系的场地以及Bob精彩的讲课。看到大家非常投入的讨论敏捷，感觉很象个大家庭，个人有个小提议，我们以后时机成熟时可以成立个敏捷之家的论坛，这样大家也可以平时把问题提出来，共同探讨交流，再定期组织面对面会议，因为北京太大了，毕竟大家东南西北聚一起一次也很不容易。 一米阳光 20:51 感谢大家的分享！ 兔子 20:57 今天Bob和王老师辛苦啦![抱拳] 黄x 21:47 感谢bob和王老师给我们提供了这么好的公益课，希望以后能继续组织下去。感觉大家今天讨论的意犹未尽，希望以后可以组织一些专题的分享和讨论，深入某些焦点话题，希望大家碰撞出集体智慧的火花。 春儿 21:49 很获益，谢谢王立杰和Bob给大家创造的机会，也感谢热爱公益的敏捷爱好者们。 Light Cavalry 21:50 谢谢王老师，bob和小伙伴们，引发很多思考和讨论，加油[表情] ppt可以从以下途径下载 https://www.slideshare.net/bob_jiang/agile1001-open-course-1 （需要翻墙） https://www.360doc.com/showWeb/0/0/344800686.aspx https://www.docin.com/p-754177054.html 合影 -———————————————————————- 微信公众号: 敏捷那些事儿（agileplus） Agile1001公开课，每月一次，旨在推广和传播敏捷开发思想和Scrum，希望更多的开发者受益。欢迎关注。课程信息会定期发布，敬请关注。公开课汇总链接。
2014/1/12
articleCard.readMoreSprint评审会议而不是Sprint演示会议
译者注：本文虽然是在辩解“sprint评审会议”和“sprint演示会议”的字面含义，但需要更深入了解其背后的原因，这其实才是作者的初衷。 （sprint评审会议=sprint review；sprint演示会议=sprint demo） 几乎每周我都会拜访一到两家公司，在现场教Scrum课程或者进行敏捷指导。最近，在上课前参加敏捷培训的人很可能有一些Scrum经验或（通过书或视频）接触过——大多数情况下，这是件好事。 但我得吐吐槽。当人们把“sprint审查会议”实践当做“sprint演示会议”或只是“演示”的时候，我是有所担忧的。这看起来只是一个语法问题，然而把评审叫做演示的结果是，它破坏了sprint评审会议的真正目的。 尽管演示是sprint评审会议中很有用的一部分，但这不是评审会议的目的。sprint评审会议最重要的方面是深度交谈和参与者之间的协作，以及使产品知识浮现出来并开发。 已经构建好的内容演示，只是一种激发围绕具体事情交谈的、非常有效的方式。而忽略了关于产品是如何工作的交谈。 下图会澄清我是如何看待sprint评审会议活动。 在图的中间，你会看到sprint评审会议图标。这个活动的关键是检视与调整sprint过程中产出的产品增量。这个图标的下边你会注意到一种举办sprint评审会议的方法。 第1步是回顾sprint目标和承诺的特性集，并和实际完成的进行对比。第2步是演示和讨论完成的特性，并对产品backlog或者发布计划做出必要的调整，以反应讨论中新的认知，然后重复这个步骤。这个循环直到所有完成的特性讨论完才结束。 在这个方法中，演示只是sprint评审会议中的一个活动，它不是sprint评审的目的。这就是为什么我认为这个很重要，应该叫sprint评审会议，而不是sprint演示会议。 再次重申，sprint评审会议的目标是检视与调整构建的产品。成功的评审结果是双向的信息流动。不属于Scrum团队的人也可以得知开发的成果并帮忙指出方向。 同时，Scrum团队成员通过频繁的反馈而加深了对产品的业务和市场认识。所以，sprint评审会议是一个检视和调整产品的预定机会。 应该叫做sprint评审会议，而不是sprint演示会议，对于这个观点，您同意吗？请留下您的建议。 原文链接：You can view the original content here. 原文作者：Ken Rubin 译者：姜信宝Bob Jiang
2014/1/9
articleCard.readMore敏捷之旅志愿者回顾会议纪要
本次回顾会议，采用的是焦点汇谈法（ORID），具体方法介绍参考链接。 下面是会议之前收到的一些反馈： 【在回顾会议时忘记和大家同步了:(】 1. 话题收集，可以考虑提前半年开始准备。 2. 场地有些窘迫。 3. 希望和演讲嘉宾有后续的交流 4. 海丁报名信息有点乱 5. 定期的微型实践活动，类似伍斌的代码操练，以此为大型活动提前预热 6. 主题分类、嫌弃通过咱们来组织，逐渐和企业联合，培养企业级用户 7. 采用互联网思维，免费、渠道、规模和自维护 8. 希望以后能有个固定的据点 9. 内容强度挺大，下午的分享形式上互动多一些 10. 整个活动中，对参与者的引导不够，大家都在尽力，但有些地方成为真空区域，尤其是洗手间的环节。 11. 收集参与者的反馈，我们需要反思为什么没人愿意来写下意见。 12. 结束的时候，三个会议室没有统一。有的会议信息只有主会场的参与者知道。（比如最后的分享途径） 下面是今天回顾会议的简单记录： 客观事实： 总结出几点为 1. 演讲嘉宾内容丰富，尤其以伍斌、王明兰和李忠利的分享突出。 2. 对创新工场的环境很满意。 3. 志愿者都很热心，积极。 下面是具体的： 演讲嘉宾选择 收尾匆忙（视频发布） 明兰的游戏 会场的安排，加强 第一次开会，很多道具，便签，海报纸。 谢钊对于关键时间点的把控 小泽的海报，很出彩。 黄喆很热心。 布航夜班后，直接参加开会。 伍斌的coding dojo粉丝很多 李东对自己的收获。 午饭后，座位上的垃圾盒，和小橘子 时间安排紧张； 会后ppt的总结，（宣传的不够啊）会上提前通知 演讲嘉宾分享水平和内容 热情高涨；预演排练不够充分 人比较坦率。 四惠太远了。 王立杰，Julie的话题很喜欢 程序员很喜欢编程操练（提前统计人数） 创新工场会议室、办公环境 黑板报，洗手池很震撼 百度的分享 明兰的分享 伍斌的分享 缺少一个整体进度，蓝图的东西。 需要一些延续性的内容。（微博，微信宣传） 第一次志愿者会议 分发午餐的时候，很忙 很高兴的事情，在工场布置圣诞氛围 晚上聚餐的时候，大家聊的很开心 伍斌和明兰的分享 应用PDCA；制定计划，及时反馈； 如何跟大牛学习；（不要事事去问，而是观察大牛是如何做的）（无政府和自组织）
2014/1/4
articleCard.readMore《Scrum敏捷产品管理》读书笔记
提到产品管理，在Scrum中，首先就想到的角色是产品负责人。因此我们先来看看产品负责人（Product Owner），以及这个角色的特征： 预言家和实干家 领袖和团队成员 沟通者和协商者 授权和承诺 时间充足和胜任工作 然后对于大型产品而言，一个产品负责人是不够的，所以存在产品负责人扩展的问题。有以下几种： 首席产品负责人 产品负责人的层级结构： 对于产品负责人，常见的问题有： 产品负责人不给力 产品负责人的工作超负荷 产品负责人的角色被割裂 远距离的产品负责人 代理产品负责人 Kano model （卡诺模型）可以帮助我们选择合适的功能，开发出吸引人的产品。 产品Backlog梳理的步骤： 发掘并记述新的条目，根据真实情况改变或移除已有条目。 按优先级对产品baclog排序。将最重要的条目放在顶部。 为接下来的sprint计划会议准备好高优先级的需求条目，对其分解和细化。 团队估算产品backlog条目的规模，添加新条目到产品backlog中，改变现有条目，并修正必要的估算。 对产品backlog按优先级进行排序，如何排序？由于单个产品backlog条目可能非常小，难以按优先级进行排序，因此最好先对主题进行优先级排序。然后，我们再对主题内或跨主题的条目按优先级排序。排序所涉及的一些影响因素：价值；知识、不确定性和风险；可发布性；依赖性。 评估需求条目的方法有：故事点，可以使用的工具：计划扑克。 产品负责人的六大罪与责：
2014/1/3
articleCard.readMore把书包扔过栅栏
前几天听到一个故事，“把书包扔过栅栏”。意思是说，把你的书包扔过高高的栅栏后，你就会想尽一切办法翻过栅栏，去把书包找回来。 这个故事的隐喻是：如果对于做某事有想法，那么就把想法说出来，说给尽可能多的人听，这样你就会有动力去实现这个想法。（公众压力） 昨天，我也终于把书包扔过了栅栏，参见Agile1001敏捷公益课#1——敏捷和Scrum角色介绍。 今早在网络上查了一下，有关这个故事还有另外2个版本（但中心思想是一致的） 1. 在《演讲达人成长记》中，Alex Cheng提到的“把戒指扔过栅栏”。 2. 在褪墨的博客中，有一篇《学会把帽子扔过栅栏与风险控制》。以下是关于帽子的故事——“把帽子扔过栅栏”摘自《女子文摘》2006年04期： 一天，在教堂义卖翻找捐赠品时，偶然发现了一个盛着一套模型船元件的盒子。那是多年前一个朋友送给我的，到现在还没有打开过。由此我想起了一些我本该做而一直未做的事情。想我这样遇事不果断、办事拖拖拉拉的人终归难成大事。 我把盒子拿在手里翻来覆去的看，脑海里浮现出父亲年轻时所拥有的一只真船——“迪克西”号，我从未亲眼看见过他那只心爱的真船——但我们家的相册里有几张发黄了的照片：父亲站在他的船上，紧挨着船轮，神气十足。在过去很长时间里，我不知道这只漂亮的白色摩托艇究竟到哪里去了。但我长到10多岁时，有一天父亲极力劝导我做一件我一直逃避干的事情，他说：“把你的帽子扔过栅栏那边去。” “我不明白您的意思。” 他笑了起来：“当你面对一排难于翻越的栅栏时，先把你的帽子扔过去。然后你就不得不想出到达栅栏那边去的办法来。”他一边笑，一边回忆着往事，“我就是采取这样的方式来芝加哥的。” 父亲在威斯康星州的拉辛市长大。拉辛在芝加哥北面约60英里处。我曾感到疑惑的是，他是如何离开家庭和亲友，置身移居到这个大城市的。 “当时我刚刚20岁。”他说，“除了那只船外，我一无所有。一个夏天的早晨，我包了几件自己的衣服，驾起‘迪克西’向南开去，一直驶进芝加哥的贝尔蒙特港。”第二天，我就进城去找工作。工作很难找。我差一点放弃梦想，调转船头家去。但我‘帽子扔过了栅栏。’“他叹了口气，接着说：“我卖掉了‘迪克西’。我要想在芝加哥扎下根，总得有一笔钱。没有了船，我也就没有了退路。” 后来的事我都知道了：他在爱迪生集团谋到了一份工作；在一个舞会上认识了我母亲;终于在芝加哥发了迹，过上了富裕的生活。但我尤其不能忘怀的是父亲的经历所给予我的启示：投入才能成功。 父亲卖了“迪克西”后，他没有了别的选择，只能把全部能力倾注在为自己创造新生活上。这个道理也为我们生活中无数其他类似的情形所证实。当你做出某种果断的举动后，就已把自己置于一种成败未卜的境地，这时你不得不想尽一切办法“翻越栅栏。” 例如，我妻子贝蒂和我早就想把我们的起居室油漆一下，可就是老拖着不动工。终于贝蒂“把帽子扔过了栅栏，”她说：“我已经邀请了一些朋友星期日晚上来我们家吃茶点并参观我们的起居室。”于是家里很快买来油漆，两天后屋子就焕然一新了。 我们房子的前主人为了把卧室的一个窗户改成壁橱，就从外面把窗户封堵了。贝蒂和我念叨了好几年，说要把那假墙拆除，以改善室内的光线。但这“工程”对我们来说似乎太艰巨了。后来我弟弟赫布，这个热心而又会干活的小伙子，来我家拜访时听到了关于窗户的事。他先在假墙上钻了个窟窿以示马上动工的决心。“小菜。”他肯定地说。使我惊讶的是，他说着就麻利地从窟窿处撤下一块墙板来。我和小儿子基特也动手和他一起干。天黑以前，一个雅致而又明亮的窗户再次出现在我们卧室的墙上。完工了，我们才知道这活儿的确很简单。我们原先想象得太复杂了。但如果不是我弟弟替我们把帽子扔过来了栅栏，这工程不知还要拖到何年何月呢。 今后当你碰到似乎很困难甚至看上去不能办到的事情时，不妨也把你的帽子扔过栅栏去，哦，你问我在我家阁楼上发现的那盒模型船元件怎末样了？当时我儿子彼得一家打算过几个月就搬家，我把帽子扔过了栅栏，答应儿子马上把模型船组装起来，然后把它作为乔迁的礼物送给他。 我组装好了那只船，我儿子一家非常喜欢它。
2014/1/2
articleCard.readMoreAgile1001公益课#1——敏捷和Scrum角色介绍
自从2001年敏捷宣言以来，全球各地都在传播和推广敏捷。但为什么使用敏捷，具体在什么场景下可以使用敏捷，以及敏捷到底能解决什么问题，诸如此类的各种问题仍然在困扰着很多开发人员。而Scrum又是什么，它能否解决软件开发中的问题，也同样令人头疼。 2014年1月12日下午2:00-5:00在这次敏捷公益分享中，将包含以下内容： 为什么使用敏捷 什么是敏捷 敏捷能解决哪些问题 爱立信的敏捷之路 什么是Scrum Scrum中的角色有哪些 …… 我是姜信宝 （Bob Jiang），我的博客https://bobjiang.com 我喜欢新鲜事物，喜欢读书，喜欢分享。愿意和大家共同进步。 正在翻译Kenneth S. Rubin的《Essential Scrum》 联系我：jiangxb@gmail.com 新浪微博: @姜信宝Bob 微信公众号: 敏捷那些事儿 敏捷公益课，每月一次，旨在推广和传播敏捷开发思想，希望更多的开发者受益。欢迎报名。课程信息会定期发布，敬请关注。
2013/12/31
articleCard.readMore说说2013年我读过的那些书
2013年读书汇总（基本保证每月一本书，并记录读书笔记）： 有部分的读书笔记没有发布在博客上，只在印象笔记中有。2014年会每篇笔记都发布在博客上。 2013.12 谁说我们不能一起做决定——参与式决策引导宝典 2013.11 This is Lean 2013.10 如何说孩子才会听怎么听孩子才肯说 2013.9 驱动力 2013.8 GameStorming 2013.7 一分钟演讲人 2013.6 AgileCoaching 2013.5 精益创业 2013.4 自控力 -———————————————————————- 微信公众号：敏捷那些事儿 Scrum和敏捷公益课，每月一次，旨在推广和传播敏捷开发思想，希望更多的开发者受益。欢迎报名。课程信息会定期发布，敬请关注。
2013/12/29
articleCard.readMore《谁说我们不能一起做决定？参与式决策引导宝典》读书笔记
本书作者是山姆 肯纳（Sam Kaner），由洪慧芳翻译（繁体中文版）。这本书是Ripley赠送给我的，仔细阅读后发现是一本关于群体引导（或者说针对工作坊或会议）非常棒的书。 本书的核心是参与式决策的钻石模型。 我们为什么需要参与式决策（Participatory decision making）？本书也解释了其核心价值： 全然的参与 相互了解 具包容性的解决方案 责任共享 参与的价值所带来的益处： 引导式的倾听技能有哪些？ 简要重述 诱使人们充分表达 镜映 收集想法 排序发言 追踪主题 鼓励 平衡 为安静的人制造空间 肯定感受 确认 发挥同理心 刻意沉默 连结 倾听共同点 抱持观点倾听 针对倾听（或沟通）的总结有五个步骤 1. 重述最初启动讨论的问题：“我们刚刚一直在讨论各位计划的成功。” 2. 指出你听到的关键主题数目：“我想大家提出了3个议题。” 3. 说出第一个议题，并列举一两个与该议题相关的重点。“第一个议题是关于你们的策略。你们探讨了策略的效用，并提出了一些需要进行的改善。” 4. 针对其他议题重复一样的顺序：“另一个议题与你们主要目标的正当性有关。你们质疑目标是否实际可行。最后，你们检视了一些人事议题，并增设了一个新的职位。” 5. 以一段话衔接到下一个主题：“我们已经思考过计划的效益了，现在让我们来讨论你们想提议出来的具体改变。” 板书的技巧 大致包括如下方面：字体、颜色、符号、格式、间隔以及秘诀和技巧。这一章都是非常具体和实用的技巧。 参与讨论的形式 列举一二，比如依序轮流发言，小组讨论，金鱼缸等，书中共提到12中参与形式，需要做不同的尝试。 头脑风暴的基本原则： 1. 每个贡献出来的想法都是有价值的。（即使是荒诞不经、超出常理的想法；即使是令人困惑的想法；即使是愚蠢可笑的想法）。 2. 悬挂判断（我们不会批判彼此的想法；我们不会审查自己的想法；我们会将这些想法留待后续的讨论）。 3. 在这个过程开始前或结束后，我们可以修改它的流程，但是不会再进行时修改。 引导者进行头脑风暴的要诀： 在长清单中挑选优先项目的方法、做法、以及优缺点 展现支持的态度 同意的阶梯
2013/12/28
articleCard.readMore我从Linda Rising身上学到的
2013年，最兴奋的一件事情就是认识了Linda，并有幸和Linda近距离接触，交流。从而在Linda Rising身上学到的很多，下面就分享其中最重要的两点： 1. No retirement – 活到老，干到老。退休后为兴趣而工作。 针对这一点，我的感想是：一定要有自己的兴趣爱好。如果能为兴趣而工作，也是极好的。 另外就是读书，坚持不懈地读书，读各种书。 Linda给我推荐了3本书（已经列入我的读书计划中） 《Strangers to Ourselves: Discovering the Adaptive Unconscious》 《A Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure Series)》 《Thinking Fast & Slow》 2. 80% for every meal – 每顿饭只吃八成饱。 为了保持身体健康和心情愉悦，每顿饭不要吃撑，只要八分饱。回应这句话，中国有句古话叫做“早饭吃的像皇帝，午饭吃的像将军，晚饭吃的像乞丐”。因此不要吃的太多，那样会长胖，也会让大脑陷入缺氧的环境。
2013/12/26
articleCard.readMore敏捷之旅2013北京站总结 - 演讲嘉宾ppt汇总篇
敏捷之旅北京站已经落下帷幕，有很多朋友问我从哪儿可以下载各位演讲嘉宾的ppt。现在所有讲师ppt已经上传到新浪微盘上，可以关注新浪微博@敏捷之旅北京。本文也对所有演讲材料进行了一个汇总，方便各位朋友进行统一下载。 所有PPT下载集合直通车。 王立杰 10年前，互联网大潮改变了我们的日常生活，重塑了很多传统行业；现今，移动互联网再度来袭，对传统企业的冲击、改造将会更大、更快，未来的每个企业都可能成为移动互联网企业；未来，只有敢于创新、敢于求变的企业才能适应不断涌现的新技术、新模式的冲击。 从敏捷到精益—创新型企业必须面对的挑战 - https://t.cn/8kQHnpy 蔡德辉 敏捷团队的一些分享，团队、客户、环境、规则，以及发展建议。 敏捷团队生存 - https://t.cn/8kRMQSl 陈勇 本主题取材于演讲者自身在产品管理中的经验，并融合了精益创业的一些概念，帮助听众学习如何迅速分析和创建“最小可用产品（MVP）”。 敏捷开发版本规划 - https://t.cn/8kRS8kb 杜伟忠 高效团队的三个习惯，进化：避免不切实际的里程碑，持续地短期胜利大于一次长期胜利。所有权：所有权需要建立一种团队文化 — 发现、认领、解决 透明：开放空间、参与而不是传递、小团队 高绩效团队的三个习惯 - https://t.cn/8kRMOyi 王洪亮 首先向大家抛出问题：传统原型法遇到什么问题？然后为大家介绍解决方案快速可工作原型，怎么进行快速可工作原型的做法技术展示，从案例中引导出什么是快速可工作原型。通过问题-》方案-》实践-》总结的思路向大家展现快速可工作原型带来的益处和挑战。 快速可工作的原型 - https://t.cn/8k8heM2 伍斌 为什么说软件开发中的三大顽疾“需求总变化、文档总过时、成果总离谱”的两大根源是需求描述的二义性问题和文档代码的分离问题？能否将文档与代码合二为一？ TDD / ATDD / BDD: 如何解决代码总难改、文档总过时、成果总离谱这三大顽疾 - https://t.cn/8k8hQnr Coding Dojo - https://t.cn/8kTKkVT 欧阳旭东 通过具体项目案例，向大家展示敏捷之魅力 Agile In Action - EVAI Agile Adoption - https://t.cn/8kQQanM Julien Detail：This is an interactive and fun session where attendees will understand: - What is Lean management - What is Kanban；- What is Lean Startup； - How the Kanban and Lean startup are both Lean by solving different kinds of problems.
2013/12/25
articleCard.readMore有趣方式的回顾会议（Retrospective）
Retrospective是最有价值和重要的Scrum会议。这是一个改进会议，通过该会议团队回顾什么地方可以改进，以及讨论如何确保阻碍团队达到目标的问题，在以后的迭代中不会再次发生。 不幸的是，回顾会议经常被忽略，并可能变成单调无趣的会议。然而，回顾会议也可以组织得令人愉快和有趣。为了保持团队的参与和兴趣，最近我采用了Mark Summers博客中推荐的帆船回顾会议(Sailboat retrospective)。（也可以参考之前我翻译的敏捷回顾的大船） _wow!!_ 回顾会议的结果令人难以置信： 来自团队稳健可行的意见 意见的目标都是为了改进迭代 团队自由地分享思考和想法 团队积极地参与 有效可行的投入 帆船回顾会议Sailboat retrospective .JPG”) 团队冒出一个下次回顾会议的创新建议。 **赛车回顾会议Race Car Retrospective ****** 图像只是一种表示方法，不包含任何实际数据。建议大家研究试验不同的回顾会议方法，并分享你的发现。 原文链接：https://www.scrumalliance.org/community/articles/2013/december/retrospective-the-fun-way
2013/12/23
articleCard.readMore敏捷之旅2013北京站 - Bob Jiang的总结
敏捷之旅2013北京站在经过3个月的精心准备与筹划后，终于结束了。 2013年12月21日，早7点，天还没有亮，我已经出发去往敏捷之旅的地点，创新工场。（题外话，上班都没走过这么早） 赶在7:30到了工场，开始最后的布置和工作安排。最关键和重要的一环，就是早上的签到。 敏捷之旅和创新工场在一起，会是一个什么结果呢？ 身兼两职真的是一个挑战（会务组织和主持人）。等我在签到台处理完紧急事情后，返回会场是8:55分，距离开始只有5分钟。在会场进行一些基本准备后，就开场介绍了。 今天到会的参会者真的可以用人山人海来形容:) 把希望树彻底挤满了，后面还有一些朋友站着听。 介绍一下敏捷之旅是什么，再介绍一下志愿者（小伙伴们），接下来是主办方，赞助商和合作伙伴。然后就介绍第一场的演讲嘉宾王立杰。 下面说一下几个话题我的感受： 蔡德辉： 《敏捷团队生存的一些思考》 首先介绍了什么是敏捷团队，通过几个非常生动形象的比喻、例子给大家一个印象。共同的目标，动作要快，艰苦训练，分工协作，统一指挥，以及给出非常有用的团队建议。 接着用敏捷里面最常用的比喻，鸡和猪的故事，来说明客户在敏捷开发中的位置，也包括老板对于敏捷开发的影响。 然后用NFL来说明团队的环境对于团队的影响。这里提到了万恶的KPI（绩效考核），这个问题接下来引发了热烈的讨论。几个演讲嘉宾都对KPI做了描述。 最后提到的是规则，在敏捷开发中团队需要遵守什么样的规则。给出腾讯和化为的敏捷开发模型。也把Scrum，XP，TSP，RUP以及瀑布式开发做了详细的对比（数据来源于Caper Jones）。 最后蔡总的演讲风格也是风趣幽默，大开大合，不仅有实例，也有数据，引发听众的思考。 李忠利： 《互联网软件开发三板斧》 软件交付模式： 检查需求抵达的方式（控制需求数量） 检查需求处理工作的方式（统一接口）：分拆需求，沙漏，Story。 拆小后，交付速度增快。 平衡价值和适应性管理 聚焦价值（必须有所舍弃）。农耕文化 vs. 游牧文化 （非常好的比喻） 聚焦后，需求质量提升 比交付模式更重要的是什么 前面那些都不重要。从精益创业顿悟：做正确的事情才是第一位。 张瑞敏给《管理3.0》的序中提到：只要找到路，就不怕路远。 最后是我在微博上收集到大家对于本次活动的反馈： _京东PMO总监 @PMO之道—蔡德辉_ _的下列看法很有启发：1、每种工具用处、局限同时存在_ _2、项目管理工具是技术人员开发出的，局限明显，对经营考虑不够。我大概是现场最年长的，但依然“敏捷‘，2014多个组织级项目管理体系项目即将启动_。 创新工场：_创新工场和敏捷社区联合主办敏捷之旅北京_ _2013。在希望树下，多位具有丰富实践经验的大师级人物正在与大家分享Keynote、Openspace、软件匠艺、看板管理等超值干货。期待参与者们在敏捷之旅中都有所收获！_ _有一个自认为右派的敏捷圈朋友，跟我聊，我说：你哪是右派，世界观比我还左，你对未来的愿景几乎就是共产主义，还是早期理想共产主义愿景。敏捷中的平等，自组织，自实现，突破限制都带有明显的共产主义色彩_。 E路向前–李忠利：于总看的真清晰。从敏捷教练和一些团队，肯定提共产主义的，但这个根本不重要。这些方式方法，如果不能有效的为业务和经营服务，就没有什么价值。我知道有人肯定会喷我。//@于忠东_咨询式培训: “经营导向、客户意愿、流程、绩效管理“是否仍然是”敏捷项目管理”背后的看得见或者看不见的手？
2013/12/22
articleCard.readMore敏捷之旅2013北京站活动12.21
2013敏捷之旅（北京站） --精益敏捷交响曲 还在敏捷的迷途中徘徊吗？ 还在精益的道路上困惑吗？ 还为拓展工程实践苦恼吗？ 年关将至，在这收获的季节敏捷之旅2013北京站强势来袭，邀请到多位具有丰富实践经验的大师级人物为大家带来Keynote、Openspace、软件匠艺、看板管理等超值干货，来敏捷之旅2013北京站，和我们一起演奏、一起聆听。 日程表 演讲嘉宾、演讲主题简介 王立杰，高级咨询师，曾就职于多家跨国公司，在电信、互联网等多个行业从事软件开发多年。过去的几年中，作为敏捷主要的实践者及推动者，带领多个团队实现了敏捷软件开发的革命性转变，继而带动整个组织的敏捷化。通过对多个组织内部团队的敏捷培训与咨询，从中积累了相当丰富的敏捷开发与项目管理方面的知识，并总结出了一套敏捷最佳实践。曾为爱立信、朗讯、VMware、Nokia、E人E本、百度等多家公司提供培训或咨询服务，曾于2009年6月合作出版国内第一本小说体敏捷著作 ——《敏捷无敌》，2013年合作出版敏捷实施案例丛书——《敏捷开发一千零一夜》，现运营有微信公共账号：敏捷一千零一夜，微信公号ID: Agile1001. 演讲主题： 从敏捷到精益—创新型企业必须面对的挑战 10年前，互联网大潮改变了我们的日常生活，重塑了很多传统行业；现今，移动互联网再度来袭，对传统企业的冲击、改造将会更大、更快，未来的每个企业都可能成为移动互联网企业；未来，只有敢于创新、敢于求变的企业才能适应不断涌现的新技术、新模式的冲击。在面对这个挑战的过程中，仅仅快速响应、快速迭代、快速交付是不够的，我们必须追求高质量的“快”，并且保证前进方向的正确性！演讲者将会跟大家一起探讨在商业形式不断变换的情况下，一个立志于创新的企业，该如何决定产品的路线图，如何快速验证核心用户需求，如何随需而变，如何为客户带来最大价值的服务，同时最大程度的降低浪费，将敏捷与精益有机的结合起来。 伍斌(Ben)，独立匠艺程序员。专注于ATDD/BDD、重构、及遗留代码解耦的学习和实践。译有《测试驱动数据库开发》一书，正撰写《编码操练：驯服烂代码》和《编码操练：ATDD/BDD验收测试驱动开发》两书，。北京邮电大学软件工程硕士，北京工业大学计算机专业学士。20年工作经验，其中1年软件开发咨询、11年程序员、3年测试、3年项目管理；所从事的项目的主要行业为通信领域，曾在Nortel Networks（北电网络）作为软件工程师和Scrummaster工作近6年。于2013年4月6日独立创办非盈利公益软件编程匠艺兴趣社——“bjdp.org北京设计模式学习组”，每月1次带领程序员进行线下结对编程操练，至今已活动10次。 个人网站：https://www.wubinben.com/。 演讲主题：TDD/ATDD/BDD: 如何解决代码总难改、文档总过时、成果总离谱这三大顽疾 为什么说软件开发中的三大顽疾“代码总难改、文档总过时、成果总离谱的两大根源是需求描述的二义性问题和文档代码的分离问题？能否将文档与代码合二为一？什么是TDD/ATDD/BDD？它们之间是什么关系？为什么要用它们？TDD/ATDD/BDD的工作方法是什么？有哪些工具可以支持TDD/ATDD/BDD开发？TDD/ATDD/BDD适合什么项目？不适合什么项目？TDD与三种类型的ATDD/BDD的代码对比是怎样的？本次分享将为你展示TDD/ATDD/BDD是如何解决上述三大顽疾的。 王明兰，近几年在诺基亚中国区移动终端产品线研发部门任敏捷/精益教练，指导和培训领域涵括scrum 流程框架，精益原则和看板管理，产品负责人和scrum master技能的指导， 敏捷领导力的指导。此外，明兰还是企业级和大型项目质管经验的资深质量经理人，带领过多个大型复杂的移动终端项目的质量管控，精通CMMI流程体系, ISO 9001 ，精益6-sigma等质量管理体系。她是认证的Scrum Professional, Project Management Professional, CMMI 内部评估员。最近她开始运营开发经理的生涯，负责组织级变革项目和业务流程改进。 演讲主题：看板游戏 GetKanban (https://getkanban.com/)游戏是利用一套实体看板工具，让大家理解软件研发流程里看板的方法和管理机制。在看板之父David J Aderson的经典看板培训课上，这是一个必做的练习。这套游戏被David J. Aderson的学员们誉为手把手学会看板的最有效、最模拟、最互动、最好玩的方式。 通过这个游戏，你能够学会： •软件开发领域Kanban的工作流程 •Work in progress Limit的设置 •Class of service的管理 •Kanban metrics - CFD chart, control chart, spectral analysis chart •Queue replenishment •Bottleneck and blocker的管理
2013/12/19
articleCard.readMoreScrum和瀑布式开发基本原则的对比
在《Essential Scrum》一书第3章（敏捷原则）中，描述了Scrum的基本原则，以及和传统的、计划驱动的、顺序式产品开发方式的对比。许多人要求分享一下本章最后的对比表格。请看下面：请提宝贵意见！ 主题 计划驱动的原则 敏捷原则 产品开发和制造业的相似性 两者都遵循既定的流程 开发不是制造。开发为产品创造方法。 流程框架 开发是分阶段和顺序的。 开发是迭代和增量的 流程和产品可变性的程度 试图消除流程和产品可变性 通过检视, 适应, 和透明性来平衡可变性。 不确定性管理 先消除结果不确定性，在消除方法不确定性 同时减少两个不确定性。 决策 在合适的阶段作出相应的决策。 保持选择开放。 一次做对 假设我们开始之前有全部正确的信息，从而创建需求和计划。 我们无法预先做对。 探索和开发 开发当前已知的并预测未知。 赞成适应的、探索的方法。 变更、涌现 变更对于计划而言是具有破坏性和代价昂贵的，因此应该避免。 用经济合理的方式拥抱变化。 预测性和适应性 高度预测性 平衡预言性的前期工作和适应性的及时工作。 假设（未经验证的知识） 容忍长时间的假设 快速验证重要的假设。 反馈 关键学习发生在主要的分析、设计、编码、测试循环之后。 充分利用多个并发的学习环优势 快速反馈 容忍交完的认知。 组织好工作流以获得快速反馈 批量大小（在下个活动开始前完成了多少工作） 批量较大，通常100%一股脑式的。适用于规模经济。 使用较小的、经济合理的批量大小 库存、在制品 库存不是信仰体系的一部分，因此不是重点。 识别并管理库存以达到较好的流动 人员浪费和工作浪费 分配人员以达到较高水平的利用率。 关注于空闲工作，而不是空闲人员 延误成本 几乎不考虑延误成本 一直考虑延误成本。 与计划的一致性 与计划保持一致被认为是达到较好结果的首要方法。 适应并调整计划而不是遵循计划。 进度 通过阶段性进展显示进度。 通过验证可工作的成果衡量进度。 中心性 流程为中心——遵循流程。 价值为中心——交付价值。 速度 遵循流程；一次做对并快速推进。 快速推进但从不匆忙。 获得高质量的时间 在漫长的测试-修复阶段后，最后达到质量。
2013/12/11
articleCard.readMore敏捷回顾的“大船”
昨天我尝试了一种新的回顾会议方法，用来收集参与者数据。用一艘船从传统的回顾工具中摆脱出来。 参与者需要15分钟静静地写下上一个迭代中，和给定主题相关的任何想法（本文例子是达到团队目标的工作）。这个过程中，团队必须关注于3个因素：_顺风、逆风和潮流、波浪_。 顺风：让你感到高兴、工作更有效和正向积极的投入。（对应我们平常回顾会议中，哪些地方做的好，以后的迭代中可以继续） 逆风：让你减速、可以改进或者烦人的地方。（对应我们平常回顾会议中，哪些地方做的不对，以后可以改进） 潮流、波浪：没有优先处理的内容，干扰或冲突。（对应我们平常回顾会议中，我们遇到哪些风险或障碍。） 围着船贴好便签后，我们花了10分钟对便签进行分组，每个人只有10秒钟站在板前进行分组，然后是下一个人。屋子里的每个人都活力充沛地整理便签。最终所有便签都按照FRIM（Frequency and Impact，频率和影响）的方式排序好，并且选出3个条目用来计划行动。planning.
2013/12/11
articleCard.readMore激情演讲Scrum
作为Scrum教练和培训师，我们经常做展示和演讲。我知道有些人经常修改演讲内容。但是他们忽视了演讲最重要的部分：交付。一周后，大多数人只记得听到的10% —— 猜猜是哪10%呢？德克尔通讯喜欢引用SHARP原则： Stories from the heart（用心讲故事） Humor, fun（幽默，有趣） Analogies (simple, everyday activities)（类比，简单、日常活动） References (quotes)（引用） Pictures/visuals (conceptualize visuals)（图片，可视化） 好的内容可以让你的演讲很棒，而好的交付会让你的演讲令人难忘。、 十月在迈阿密我们给当地的敏捷讲师带来一场精彩的高绩效团队的大会。在筛选过程中，我们确保按照如下推荐清单进行选择。（SPR，简单，有力，相关性） 11月13日，我有机会参加了Ryan Avery的“如何成为一个伟大的演讲者”，这是他在北京之旅的一部分。(www.howtobeaspeaker.com)并且我记录了一些笔记。这些是下次我会给Scrum听众分享的内容： 演讲应该是简单，有力和相关的。 简单 保持演讲简单。简单为王。 在演讲结束时加上自我介绍。 在主体部分，只讲3个故事。 每个故事有一个要点 3个故事都围绕一个不变的主题。 有人会教你些东西，因此不必逞英雄：Ryan觉得人们不想听演讲者夸大（或抱怨）成就。通常这拉大了与听众的距离。 段落与诗歌：当写演讲内容时，停顿的时候回车换一行。这会帮你记住演讲的模式。 丢掉道具：让观众发挥想象。 用3D模式演讲。利用所有的感官。例如：嗅觉和味觉。我可以“尝一下”演讲吗？在演讲当中采用不同的感觉；但要注意使用的顺序。 强有力 如果你不得不穿过科罗拉多大峡谷，给某人带去一句话，会是什么？那个人是谁？ 不要把它当做演讲，而是来自心底的信息。 自信地演讲。用主动语态而非被动。 让我们看一下Simon Sinek的演讲https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html. 研究一下这个黄金环的概念：有3个问题：why, how, and what. 大多数人以_what_开始，接着是_how_ 最后是 why. 成功人士反之，从_why 开始，_接着是_how_ 和 what. Ryan用了一个简单的图，来说明不同焦点的方法。成功人士关注一个具体的要点（三角形的顶点），接着展开从而达到要点。 以我在迈阿密会议的为例（why为导向，开始的话）： 为了创建一个统一的社会，我们更近一步。 他们代表南佛罗里达的公司，来到这里分享经验。 今天的演讲持续交付最好的实践。、 而如果我们是从what开始的话： 我们来到一起讨论持续交付的最好实践。、 我们分享经验，并从中汲取一些教训。 我们关心社区发展。 相关性
2013/12/10
articleCard.readMoreScrum团队和直线组织兼容吗？
Scrum改变了团队成员之间的工作文化，就像Henrik Kniberg (在 Spotify) 说过, “Scrum 团队看起来更像mini创业团队。”但是这和传统的直线组织兼容吗？ 我知道所有采用Scrum的公司仍然有直线组织。直线组织的理念是为了链接组织单元，帮忙管理组织系统中的上下级关系。换句话说，所有的ScrumMasters是ScrumMaster直线组织的一部分，开发人员是其直线组织的一部分，等等。但是现在有许多已知的组织类型，混合也是有可能的。开篇的图不要太认真，但他们展示出“现代”的直线组织。 但是上下级的思想和自组织、跨职能的Scrum不兼容吗？我们真的需要一个管理角色，具有对策略和薪水等的一言否决权吗？ 或许我们可以找到一个值得思考的方法，就像Henrik提到的mini创业一样。我们如何组织mini创业，就好像员工是公司的主人一样？我个人喜欢作为团队的一份子，所有人都是平等的伙伴，和Scrum团队类似。当然角色必须是共同的；有些人必须担当PO角色，还有些人担当ScrumMaster，等等。取决于个人兴趣，这些角色可以是固定的或者轮换的。团队进行关键决策（众所周知在Scrum中团队做出承诺）。团队内还要做出决策依据，从而我们一起完成用户故事。计划会议帮助mini创业团队构造任务，而我们为下一个时间盒的迭代设定团队目标，以及审查结果——我们也通过回顾持续改进自己。 如果mini创业团队变大了，我们会把团队拆分成两个来减少开销。以我的观点，在扩张的时候有3个事情是很重要的： PO要和两个团队一起工作。 新团队成员也是平等的伙伴。 团队基于主题构建“公会”（译者注：参见Henrik写的关于Spotify Scaling Agile的文章） 现在可以说PO正在变成这个mini创业团队的经理，但这不是真的。PO仍然是平等的伙伴；他不过有其他的关注点。仍然是团队或者团队的代表根据主题做决策。组织越大，公会变得越重要；它就像粘合剂一样，把独立的团队带到一起，交换最好的实践并在主题内做出决策。例如，制定决策是PO的职责，然而分解策略应该是团队的责任。 公司组织对于Scrum团队不兼容吗？或者你如何设计理想的敏捷组织呢？
2013/12/8
articleCard.readMore翻硬币游戏（Scrum游戏）
翻硬币游戏在Scrum培训中很常用，因为它是一个很简单，但能揭示很多道理的游戏。下面我会介绍一下这个游戏的规则和所揭示的一些道理。 道具 1元硬币5枚 5角硬币10枚 1角硬币5枚 共计20枚硬币 游戏规则 只能用左手 一次只能翻一枚硬币 一个人翻完N个硬币后，才能把硬币传递给下一个人 数量N由游戏引导师指定 全场评选一名最快的人，提供礼品（可选） 游戏概述 翻硬币游戏，在网上查到最早是由Joe Little提出来的，后来Jeff Sutherland还有Crisp公司的咨询师都大力推广。我在学习这个游戏后，深入发掘发现它不仅可以用于Scrum培训，还可以用于Lean、Kanban等。 现在大多数公司都重视效率，重视时间线，而忽视了队列和批量的大小。在这个游戏中，正是通过改变批量的大小，从而改善了排队情况，进而大大提高了效率，也加快了进入市场的时间。 具体描述 游戏每组需要8-12人，每组的布局如上图。游戏里一共有5个角色： 游戏引导师 工程师（实际干活，翻硬币的人） 经理（不干活，负责计时他面前的工程师从开始翻第一枚硬币到翻完最后一枚硬币的时间） 客户（负责根据批量分发硬币，以及计时收到的第一批硬币的时间） 客户的老板（负责计时收到所有硬币的时间） 一共4轮游戏： 第一轮，批量大小是20 第二轮，批量大小是10 第三轮，批量大小是5 第四轮，批量大小是1 第一轮 客户把20枚硬币分给工程师1，工程师1翻完20枚硬币后，一起传给工程师2，2翻完后传给3,3传给4,4传给客户。第一轮结束。 经理1,在工程师1开始翻第一枚硬币时计时，翻完最后一枚时结束，记录时间。其他经理同理。 客户记录收到的第一批硬币时间。 客户的老板记录收到所有硬币时间。（第一轮应该和上面的时间一样） 第二轮 第二轮，客户把10枚硬币分给工程师1，工程师1翻完10枚硬币传给工程师2，在1翻完10枚硬币时，客户再次给10枚硬币。2翻完10枚后传给3，一直传到客户。 经理1,在工程师1开始翻第一枚硬币时计时，翻完最后一枚时结束，记录时间。其他经理同理。 客户记录收到的第一批10枚硬币时间。 客户的老板记录收到所有硬币时间。 第三轮 第三轮的批量大小是5，其他同上。 第四轮 第四轮的批量大小是1，其他同上。 反思点 批量减小，上市时间（Time To Market）缩短了 批量减小，交付时间（Lead Time）缩短了 为什么批量减小，上面的两个时间缩短了？ 当批量减小后，客户有什么变化？ 个人绩效和团队绩效的联系？
2013/12/7
articleCard.readMore“潮湿的”Scrum——Wet Scrum （译）
许多公司标榜自己在做“敏捷”。敏捷是执行软件开发的最新的框架。这个框架下有不同的方法，如Scrum，极限编程（XP），RUP等。Scrum目前是最热门的。一般来说，组织会使用一个混合的版本来适合他们的需求，也受到组织的环境限制（EEF、OPA；指的是企业环境因素，组织流程资产）(EEF/OPA, or enterprise environmental factors/organizational process assets). 因此，公司为什么要转型到敏捷呢？ 我们用敏捷宣言来概括回答这个问题： Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 敏捷赋予客户更改的灵活性，因为整个流程是迭代的并且客户知道每个迭代的进展。还有，团队计划且承诺每个迭代的工作，并一起完成承诺。 对于双方这是一种双赢的场景： 客户实时得到项目、产品的更新状态，并且客户可以自由地改变需求。 团队就像军队里的阿尔法单元（5-9个人），一起在短迭代内荣做。 不争的事实： 这些都是理论。然而生活不是非黑即白：哪里都有灰色地带。 “do Agile做敏捷”比“be Agile成为敏捷”更容易一些。敏捷需要一定的纪律来得到正确的结果。 会议在时间盒内吗？ 会议中你是很好的倾听者吗？ PO或者ScrumMaster就是唯一说话的人吗？ PO或ScrumMaster把工作“强加”给你吗？ 在Sprint计划会议时，PO不等团队的输入就要求承诺吗？ 被迫给故事ABC分配XYZ点数的估算吗？ 在回顾会议你不“公开”，因为害怕所说的适得其反吗？ 在sprint过程中你被迫承担新故事，而影响了你已经承诺的交付吗？ 在每日站会上你从来不谈论尽管已经存在的障碍？ 你希望PO或SM微管理而你只需要工作即可吗？ 你相信胡萝卜加大棒的管理方法很重要吗？ 这些场景只是其中很少的例子；可能的清单是无穷无尽的。这些表明你在“做敏捷”（只是为了完成而已），但你不是“成为敏捷”，因为你不知道敏捷实践和交付的真正重要性。 你可能是遵循瀑布式开发人的敏捷傀儡。这种Scrum是臭名昭著的“Water-Scrum-Fall”。（译者注：也有叫做Scrum-But） 我给这个方法起了个新名字：“潮湿的”Scrum 遵循瀑布式开发的实践Scrum就变“潮湿”了。人们根据场景和难度有选择的使用Scrum。然而这么做很难（几乎不可能）理解敏捷的精髓。 潮湿的Scrum如何工作 客户需要以下内容： 更多的人为干预 可控的工作组织在短迭代内，而不是把整个项目、产品作为一个整体进行管理。 事实更新完成的工作 改变需求的权利 高质量结果 这些都是Scrum理论上的交付物。然而，如果团队没有纪律性，也不关注使项目成功的话，就没有工作方法可以确保项目成功。
2013/12/5
articleCard.readMore我姐和我女友是如何学编程的（转）
English original：How my sister n my girlfriend learned to code，翻译：Ekaterina@yeeyan 就像我在上一篇博文中提到的，Eva和Fong（译者注：根据博主的上一篇博文，Eva是博主的姐姐，Fong是博主的妹子）来到旧金山跟我学编程。在这篇博文中，我将记录下我教她们的方式，我构建这种学习过程的理由，以及这种学习方式奏效的原因。虽然以时间顺序列出她们在这段时间做的或学习的每一件事再容易不过，但是这毫无用处，而且读者们也会遗漏重点。了解学习过程中的细节并且明白它起作用的原因至关重要。所以我会从基本原则开始讲。本文较长，请做好准备。 我姐和我女友是如何学编程的 请在编程过程中始终牢记这些基本原则。 1）交流沟通 在Eva和Fong开始学习之前，我为她们申请了博客，并请她们记录下她们的编程之旅和学到的东西。万事开头难，你可以问问她们。我大概花了一周的时间跟她们唠叨才让她们写了第一篇博客。但是现在，她们不在博客上写点儿自己投入了大量时间的项目就觉得不对劲。 如果你在项目中使用了API（译者注：Application Programming Interface，应用程序编程接口），发推文或者是邮件给这家公司告诉他们你关于他们的API的想法。当你在黑客马拉松中赢得奖项时，发个不错的推文@他们表示谢意，或写篇相关的博文。每写一篇博文都使它成为一直以来最好的，并怀着它会被放上黑客新闻版首页的期望将它提交（尽管大部分时候这种期望都不能实现）。 健康交流的最大好处就是，它使你对你的项目负责， 由此也引出我的下个要点。 2）完成 Fong和Eva都知道，完成一个项目困难，却重要。我声明：除非她们写了一篇关于手头项目的博文，在推特上@了API公司，并且将它发布在黑客新闻网版上，我们是不会开始一个新项目的。尽管她们的第一个项目只是井字棋游戏，但这是她们做过的最好的井字棋游戏。从来就没有人想写一个蹩脚的项目，所以不管这个项目有多简单或者不相关，如果你要着手做个项目，那它必须是你能拿到的最好的那个。我已经见过太多开发者为毫无前景的次要项目工作。如果你在学习编程，你必须从一开始就认识到要珍惜你的时间和精力，完成你的项目证明它的价值。 完成整个项目的最后20%需要花费全部努力的80%。开发者可以在1、2天之内实现一个项目的概念。而测试每种情况并且解决每一种边际情况从而成就一个“完美”的产品则需要两倍的时间。在项目最后的20%花费那80%的精力，将会在许多许多访问中传为佳话。 3） 思考 如果你卡住了，不要紧盯住你的代码。出去散个步，呼吸点新鲜空气，再考虑一下。你卡住了是因为你的逻辑中有错误，而修正它最好的方法就是在脑海中或是在纸上一步一步地彻底想通它。程序员靠思考赚钱，问题在你的思考中被解决，编程是个蛋疼的工作。伟大的项目经理通常都有广博的编程背景，并且在思考和问题解决方面接受过出色的训练。 有一种说法：当你被卡住20多分钟时，并且你仍然茫然无绪，请教别人吧。如果在20分钟内没有任何头绪，那么在接下来的一个小时，你也不会有任何进展的。相信Eva。她有一天就浪费了5个小时，因为一个愚蠢的错误——血的教训啊。散个步，做个其他事。然后再回到项目上来。能将自己与问题切断并转移注意力，是个技术活。 4）再思考 也许你现在已经明白了，思考，在一个程序员的生活中是至关重要的。不要去复制-粘贴代码，尤其当你在学习如何去编程的时候。如果你想学习怎么编程，复制，粘贴——“看，有用诶！”不会使你有任何成就。相反，无论何时你看到代码，你必须在企图去试运行它之前想清楚它在干什么。当你能轻易看懂别人的代码了，将其简化到你刚好需要的程度，然后写出来。如果从一开始就定期这么做，你会在几个月内成长为一个非凡的开发者。 5）谷歌 学会独立解决问题。除非至少被卡住20分钟，不要问编程问题。程序员们必须是独立的。他们是伟大的思想者和伟大的交流者。为了成为他们中的一员，你必须逻辑地思考，想出问题出现的原因。许多年轻开发者面对的问题是，写出他们真正需要的代码对他们来说很困难。我们中的许多人也是这样，明知道问题是什么，但就是不知道要去找什么去解决它。这是个你必须从一开始就培养的技能，它漂亮地联系了第一点，“成为一个交流者” （译者注：疑为博主手误，communication 应为communicator）。 现在，有了这五点牢记于心，以下是Eva和Fong学到的东西，以时间顺序排列。 第1-3天：通过Ruby语言学习编程基础 我选择Ruby语言，因为它用来上手是最的。在Ruby语言中，有很少语法限制（space键与tab键，类型声明，等等），所以Eva和Fong能够关注编程的思考过程而不是解决语法问题。她们学习了if型语句、循环体、数据结构，解决了一些编程题目，比如说FizzBuzz（编程初级问题，即满足a条件时输出Fizz，满足b条件时输出Buzz，同时满足a、b条件时输出FizzBuzz）,替换字符串中的字符，转换一个数组，找出最大值。关于类别和对象的学习也是重要的。 *注*我没有教她们特定的ruby语法，而是让她们对参数都使用括号，并且以返回空结束每个函数。 这样的话，她们下次学一种新的语言时就能更快上手。 第4天：HTML HTML或CSS严格上来说不能算是编程语言，所以没必要在这里花上太多时间。Eva和Fong在HTML上花了一天时间，编了几个标签玩儿，快速完成了表单、信息页等内容。这样，对CSS的兴奋感就建立起来了。在这里重点要学的是区分块HTML与内联HTML、标识与分类。 第5天：CSS 在摆弄过HTML后，“如何在那里表达这个，怎样使这个丑陋的HTML页面看起来更漂亮”的问题浮出了水面。CSS就是那个完美的答案。花上一天的时间尽情设计网页（所有HTML页面都已经在前一天建好）。这一块的重点是，相对/绝对/固定定位，HTML浮动元素，以及如何用绝对、固定定位来控制正常的浮动。 第6-7天：通过jQuery来学习javascript jQuery需要花点时间来适应，而且因为涉及到编程，学习jQuery框架需要占用点时间。她们花了几天时间将HTML页面做成交互式页面。 第8-15天：第一个项目- 井字棋 这时，Eva和Fong已经了解了HTML/CSS/Javascript，但不是特别习惯。这正是让她们开始第一个项目（井字棋）的绝佳时机。虽然她们花了两天的时间来完成这个项目，又用了几天时间来对其进行润色修饰。项目的最后20%要花费精力的80%是个金科玉律。作为一个初学者，学着去完成你的项目是很重要的。 第16-20天：Sinatra框架 在那个看起来永远都不能结束的井字棋项目之后，Fong和Eva迫不及待地想学点新东西。学点服务终端代码对她们已经在做的事来说是个激动人心的全新体验。我选择Sinatra，是因为它是我使用过最整洁、最简单的网络框架，而且这种简洁性让解释网络的工作原理变成小菜一碟。 第20-22天：Photoshop Photoshop对非凡的设计非常重要。对那些从没用过它的人来说，它有点儿吓人（至少对我来说是这样），但是用Photoshop做出来的网站比典型的bootstrap（译者注：由Twitter推出的一款开源前端框架）站点要高端一个档次。而你真正要知道的只是混合、协调功能就够了。任何一个相当成功的开发者都会需要Photoshop，所以学会它并且在你所有的项目中使用它非常重要。 第20-27天：项目2-Dragpic（译者注：通过拖动图片实现从网页上方便地保存图片的软件） 项目2涉及到Javascript的大量使用。这个项目涉及到使用ajax（译者注：一种用于创建更好更快以及交互性更强的 Web 应用程序的技术）的需要，facebook的API，以及cookies。这是个将所有网络编程基础联系起来的绝佳项目。这个项目所需要的技术范围比第一个要更广，我觉得这也向更多更复杂的项目迈进了一步。在这段时间里，她们凭借GIT（译者注：分布式文件管理工具）通力合作。这可是一个开源项目啊！ 第28-30天：RSpec 这时，Fong和Eva已经能相当自如地构造网络应用了。也正是这时，她们意识到，代码是多么地脆弱，一个细微的改动，就能导致满盘皆输。现在，测试驱动开发就显得有重要意义。我们花了几天时间重温了rspec，Eva和Fong则写出测试案例作为每天早晨的编程练习。我之前提过她们每天早晨都要解决一个技术问题吗？从第28天开始，她们就必须为这些技术问题写出rspec，在她们开始编程之前也不例外。 第30-35天:BackboneJS（译者注：一个开发网络应用的框架，提供了强大的对模型、视图和交互的抽象） 通过负责一个设计技术范围广泛的项目（比如Dragpic），你能学到很多，遇到很多你希望能有更优解的问题。只有这样，你才能这正意识到那些帮助你的框架的价值。我还没有找到任何一个优秀的backboneJS教程，所有教程都一下子提供了太多信息。以下是我教授它的方法： 第一步：学习模型。仅为一个数据库数据库条目创建一个模型。学会如何去修改和保存。 第二步：学习视图。为你已经在做的模型创建一个视图。添加事件接听程式，体会视图如何能够隐蔽地与模型连接，以及这一切组装为一体是如此地合适。 第三步：集合的意义现在就明确了。 你不可能手动打印输出每一个模型，尤其是当你不知道模型具体数量的时候。 我们没有学过常规课程，到现在为止，我也不认为这有什么要紧。 第35-40天:Android 假如你现在还没怎么注意，我们已经在短时间内涵盖了大量的材料了。伟大的程序员适应变化，因此我们最后一个计划就是学习Android系统。在编程中你不能忽视移动设备，这块实在是太重要了。我教她们Android编程，这不是特别难，Android编程与web编程非常类似。在视图上你有XML（译者注：extensive makeup language,用于标记电子文件使其具有结构性的标记语言）,同时也有足以和web控制器相媲美的Java代码。模型-视图-控制！通过用Ruby语言和Java语言工作，Fong和Eva开始寻找编程语言之前的共同点，成为了编程语言不可知论者。对她们来说，编程语言仅仅在语法上有所不同，但工作起来却是一个道理（其实不是这样，稍后我会对其进行辨析，厘清混淆）。 结论： 1）女孩们在编程上天赋异禀。 2）没有获得计算机科学的学位不是个不学编程的借口。 3）在快乐中编程，人人都能学。 继续探索，然后征服编程吧！
2013/12/5
articleCard.readMore看板披萨游戏（Kanban Pizza Game）- 译
由Agile42公司开发的看板披萨游戏遵循以下许可：Creative Commons Attribution-Share Alike 3.0 License. 仅仅通过教科书的方式传授精益敏捷的原则，是很困难的。人们必须亲身经历这些原则以体会它们是如何工作的。通过游戏，不必打乱日程工作或沉迷在技术细节，你就可以获得经验。这也是我们在培训中使用游戏和模拟的原因。如果没有合适的游戏，我们就创造一个，比如看板披萨游戏！ 通过agile42公司的这个游戏，你可以发现看板是什么。然而其他看板游戏通常关注白板概念和已有看板系统中的工作流，我们的看板披萨游戏教会大家如何从现有流程产生看板系统。 用纸做披萨 如agile42 Scrum Lego City Game，我们希望看板游戏用每个人都熟悉的东西并且每个人都能做。我们尝试远离IT环境，因此参与者不用考虑太多和他们现有工作环境的相似处。我们认为用纸做披萨这个想法太棒了——每个人都喜欢披萨，并且每人都知道披萨是怎么做的。（至少知道一般术语） 什么时候以及如何使用看板披萨游戏 如果你想要理解看板是什么，以及在日常工作之外的安全环境里实践一些精益概念，那么看板披萨游戏是最合适的！ 学习目标 从培训的角度这个游戏的目的是什么？我们希望参与者： 体验看板系统如何从已有的流程中浮现出来（如工作当中那样） 体验一个完整的看板系统（而不是只关注白板和相关概念） 理解白板是依赖于场景的：对于任何流程，都有许多不同设计的看板，这些都是适当和实用的，而不必只有一个最优的看板。 理解限制在制品（Work In Progress）的影响。 体验自组织和适应性。 充满乐趣! 每个团队都有不同颜色的纸、剪刀和其他材料（参见本页底部的完整物料清单）。团队根据配方裁剪、涂抹和粘贴这些材料以形成披萨。准备 这个游戏从开始到结束有一套PPT可以使用。（译者注：后续提供不需翻墙的链接） 确保充足的物料！ 每组至少4个人 可以一个组玩，但多组的话会增加有益的竞争，也会更有趣 (可选) 如果人数为奇数，可以考虑邀请他做观察员，担当质量监控并衡量交货时间。 游戏流程 1. 第一轮，创建一个隐含的流程 看板总是从你当前现有的流程开始的。在游戏的开始，让团队拿一些纸片并制作尽可能多的披萨（夏威夷）。如下图 展示一块做好的夏威夷披萨并解释怎么做的：一块披萨饼底（三角形纸），番茄酱（红色马克笔），3块火腿（粉色便利贴）和3块菠萝（黄色便利贴）。番茄酱要涂满饼底（译者注：记得披萨饼有卷边哦），馅料大小合适并均匀分布在披萨上。 演示烤箱盘并演示怎么用。烤箱一次最多烤3块披萨。烤的时间最少30秒。在烤的过程中不能动烤箱（增加或拿走披萨）！ 下面要求团队制作尽可能多的披萨，但要避免浪费，如准备好而不用的原材料。当你决定结束的时候（大概5-7分钟后，不事先确定时间），告诉大家停下来。 2. 介绍看板 在第一轮结束后，介绍看板和核心看板实践。 核心看板实践： 使工作流可视化 限制你的在制品数量（WIP） 管理流动（Flow） 实现反馈环 明确流程原则 一起改进 接下来，介绍计分系统并让团队自己算分。设计计分系统是为了提倡限制WIP，并且可以间接地流动（在这个游戏中，流动和交货时间是有关联的，只要人们不知道一轮的准确时长，他们就会重复相同的行为）。收集分数并记录到白板或者挂图上。 让团队把工作流可视化并且通过引入生产材料库存（披萨饼底，火腿块等）来使流程更明确。现在不要尝试优化工作流，仅仅把第一轮出现的内容记录下来。 让团队限制他们的在制品（WIP）。第一轮结束后团队有一堆的材料浪费了吗？每个步骤合理的WIP大小是多少？ 披萨的质量如何？有没有偷工减料？披萨饼底应该是一样大并且涂满番茄酱，馅料剪得很精美且分布均匀。 下轮开始之前，扔掉已经交付的披萨，但保留没有用过的材料，包括桌子上没烤过的披萨。 3. 第二轮，使用刚才建立的看板系统 现在用刚刚建好的看板系统开始下一轮。再次强调，快要结束的时候不要给出任何提示，当你觉得差不多的时候（5-7分钟后）就结束这一轮。结束后做一个小结并算分。 接着让团队花1分钟反思一下，他们的看板系统哪里挺好的，哪里需要改进，并再花1分钟重新设计工作流和尝试不同的WIP限制数目。 4. 第三轮，扩展 给游戏增加点复杂度，引入客户订单和一种新的披萨（蔬菜配方）。订单可以包含1种或2种披萨，只有整个订单完成了才能得分（订单里披萨的总分）。蔬菜披萨没有火腿和菠萝，只有7条蔬菜（绿色的便利贴）。可惜蔬菜一烤就很容易焦了，所以只能在披萨烤好后粘上。
2013/12/5
articleCard.readMore用帕累托法则管理Backlog - Pareto Your Backlog （译）
帕累托法则是根据它的发起人命名的（Vilfredo Pareto意大利经济学家）。这个概念非常简单：80%的结果来自20%的原因。 帕累托法则（也叫二八原则）可以应用到许多业务领域。比如： 在销售领域，80%的业务来自20%的客户。 在效率方面，80%的成果来自20%的任务列表。 在服务行业，80%的工作来自20%的服务产品。 在市场营销方面，80%的回应来自20%的营销工作。 在客户服务领域，80%的抱怨来自20%的客户。 在Backlog里，80%交付的价值来自20%的Backlog (如果你想了解这些数字是怎么产生的，可以参考维基百科关于帕累托分布的定义：https://en.wikipedia.org/wiki/Pareto_distribution.) 为了遵循以交付高价值和客户喜欢的功能的方式高效地管理Backlog的精神，我建议要毫不留情地清理现有Backlog中的待办事项列表。这意味着需要识别80%不能使客户高兴的特性并清除掉它们。找到20%让客户高兴的特性，交付并重复这个过程。 帕累托法则承认努力和结果之间的不平衡，并且允许我们用这种不平衡来发挥自己的优势。但这不是说我们可以不做非关键的、80%不太重要的工作。比如，我们不能忽略监管需求；但是，我们可以改变行动，因此我们关注在最需要的方面。比如，因为我们要做其他队客户很重要的特性，所以不会浪费时间在营销监管需求上。 在多个级别上都存在帕累托法则：你可以指出组合中20%的产品，它们交付了80%的价值吗？你知道这些产品来自20%的史诗(epic)故事吗？当把史诗故事拆分成更小故事时，团队知道20%的关键任务交付了80%的价值吗？ 应用帕累托法则 在Backlog中应用帕累托法则的关键是，需要关注其中关键的20%，这些实现了80%的客户满意。当然这是一般原则，而不是确凿的统计数字；对于某些条目，分界点可能更接近90/10或者70/30。但要点是一样的，当你开始查看交付了哪些让客户不高兴的特性时（或者是客户根本不用的特性），帕累托法则是出奇地准确。 应用帕累托法则的难题在于识别关键的20%。在某些领域有可衡量的指标（比如客户数、收入以及每个服务的时间），这些很简单。当在Backlog中有一个冗长的待办事项列表，里面有许多条目需要完成时，做同样的分析会很困难。我的建议是不停止交付，而是跟进已经交付的工作，看一下产品是否真正满足客户了。如果你花了大量时间完成80%底部的特性时，或许下一次你不会这么做。为什么我们喜欢衡量成功，事后分析是20-20，当确定要做的20%时，通常你也准备完成20%的改变。（Why we like to measure success here is because hindsight is 20-20 when determining the 20 percent to concentrate on, and many times that 20 percent changes by the time you’re ready to address it.）如果跟进正在交付的内容，真正衡量客户的满意度，你会看到交付Backlog中更高价值的持续改进。 How High? 就用这个思想做个实验： 团队一年的成本——假设100万元。 用这个成本团队交付的价值——团队交付了一年300万元。 我们再做一个假设：我们一起工作的PO，有另一个Backlog，价值比现在的高10% 另一个假设：或许PO通过愿景激励团队，移除障碍，并且团队开发速度提升了。 最终，Backlog中应用帕累托法则（20%的backlog交付了80%的价值，并且PO依此组织backlog）并回答下面这个问题： “PO一年可能交付多少价值？” 帕累托法则这个概念是非常高明的. 原文链接：https://www.scrumalliance.org/community/articles/2013/december/pareto-your-backlog
2013/12/3
articleCard.readMore回顾会议的反思 - Retrospectives（译）
回顾会议是Scrum的一部分，用来反思完成的工作，从而帮助团队提高（自组织和定期调整）。然而，我目睹了许多团队的回顾会议，他们会议变得单调地重复或者变成“形同虚设的会议cribbing sessions。”回顾会议往往就得到扩展（不是在限定时间内完成），并且通常不产生任何实际的改变（业务价值），也不识别和解决问题。 如果回顾会议进入这种状态，那么是时候改变了，你应该引导团队并且关注于给出会议的方向 ，确保回顾会议在时间盒内并且最后有可量化的行动项。 为无方向的回顾会议给出方向 如果团队想要走出这种困境，通过建议讨论的主题而给出一个会议结构（日程），很可能是个不错的注意。下面是一些有用的建议： Sprint planning: 我们的计划够好吗？在迭代中碰到问题了吗？ 每日站会: 我们如何有效的开每日站会？ 持续集成: 为了提高效率，还有哪些可以放到持续集成内的？ 时间盒交付: 我们能交付承诺的内容吗？ PO的反馈: PO在澄清需求方面是如何回应的？ 协作: 我们（团队）之间是如何协作的？ 回顾会议: 通过回顾会议我们有所经验和教训吗？ 你可以根据自己的环境和需要调整上面的列表。 关注问题的数量而不是质量 为了避免主观或定型的发言，建议团队使用一个打分系统（从1-最低到10-最高）。调查结束后，团队就会得到一个当前迭代的平衡计分卡，因此很容易找出表现最好和最差的地方。 下面我们看一下 如上图，团队能够发现强项和弱项的地方，然后可以选择最好的（1或者2项）和最差的（1或者2项）进行讨论。（译者注：最好的1项和最差的1项，在上图中是协作和时间盒集成）这就是我们的回顾会议要做的事情，如何改善弱项，以及如何进一步提高强项。 持续地监控回顾会议 这些分数给了团队开会和讨论的结构化的方法。然而，做为ScrumMaster，定期监控会议的价值也是非常重要的。因此我建议你维护一个所有迭代对比的趋势报告。如下图： 通过分析过去几个迭代的进展，你应该可以识别出以下点（译者注：参考上图的Trend列）： 低谷期: 持续得分很低的问题或者有下降趋势的问题。 平台期: 相对稳定但还没有达到“绿色区”的问题。这可能表明团队中酝酿着停滞或漠不关心的情绪。 顶峰期: 团队持续改进的方面，或者在相当长时间内维持在“绿色区”的方面。 在某些点，可以考虑从计分卡中移除“顶峰期”并引入新的主题，从而可以保持关注于低谷期和平台期。这会帮助你从不同的方面评估立足点以及帮助突破团队内单调的风险。 正确使用回顾会议时，它可以洞察团队的健康度并突出改进的范围。如果不满意你的回顾会议，那么改变它！ 原文链接：https://www.scrumalliance.org/community/articles/2013/december/introspect-the-retrospectives
2013/12/2
articleCard.readMore有效沟通之倾听
沟通当中最重要的是倾听，而不是说。 还记得有这样一个故事： 有一天，一个说话连篇、滔滔不绝的人来找苏格拉底。他问到，我如何学会沟通。我认为我很会说，但是为什么没有人愿意听我讲。苏格拉底回应道，我应该收你两份钱，因为我要先教会你闭嘴，然后才是如何说。 通过这个故事，我们得知沟通的时候，首先需要倾听。只有真正地做到用心倾听，才能打动对方，建立彼此的信任与联系。 如何做到倾听呢？ 这里有几个方法，非常实用（节选自《参与式决策引导宝典》： 1. 简要复述：顾名思义，用自己的话重复对方刚才所讲的内容。这样做有几个好处，第一说明我在认真的听对方讲；第二得到对方的核实，如果复述有误，可以第一时间重新站在同一跑道上。 例句：“听起来你的意思是……”，“不知道我这么说，是不是你的意思……”，“……我有没有理解你的意思？” 2. 引导对方充分表达：应用场景，a.帮对方厘清思路。b.对方自以为说清楚了，可听众迷迷糊糊。 例句：“你可以说的再具体一点吗？”，“你现在想到的是什么？”，“你可以举个例子吗？” 可以先使用简要复述，然后使用连词加上引导的句子。 3. 求同存异：沟通当中难免有冲突，但再大冲突的观点，也有相同之处。沟通当中我们需要寻求这样的共同点，来找到两全其美的解决方案。 例句：“让我归纳一下每个人的说法。我听到很多不同的观点，然而也有相似之处。”“听起来有些人希望在新年假期可以早点下班，有些人则宁可正常上班，但要放几天假。” “虽然如此，你们似乎都同意在过年前想要某种形式的休假。” “我这样说对吗？” 4. 同理心：了解他人的感受，和感同身受。最基本的技巧是，说出你觉得对方正在经历的感受。但一定要做确认，鼓励对方纠正你的猜测。
2013/12/2
articleCard.readMore认同和确定性矩阵（Ralph Stacey's Agreement and Certainty Matrix）-译
基本概念: 这是一个在复杂的、自适应系统中选择恰当管理行为的方法，该系统是基于所涉及问题的确定性程度和认同级别的。 潜在使用场景: • 为特定的问题或决策选择管理或领导方法。 • 制定一组决策（或大家的日程）的意识。 • 与人沟通，为什么特定的方法是合适的。 • 当需要创新和创造性选择时，这个矩阵可以用来有意地增加不确定性和不认同，从而把系统轻推到混乱的边缘。 描述: 管理和领导的艺术是拥有一组方法，并且知道什么时候用哪个方法。Ralph Stacey 提议了一个对管理艺术有帮助的矩阵，这个矩阵在两个维度上识别管理决策：确定性程度和认同级别。 我们来仔细看一下这两个维度。 接近确定性: 当因果关系确定时，问题或决策也接近确定性。当过去一个相似问题或决策发生时，通常是这样的。人们可以非常确定地从过去推断和预测行动的结果。 远离确定性: 确定性连续的另一端是远离确定性的决策。对决策制定者而言，这些情况常常是独特和新颖的。因果关系不是很明朗。从过去的经验推断，在远离确定性的范围预测不是一个良好的方法。 认同: 竖轴代表团队或组织内关于问题、决策的认同级别。和预想中的一样，依赖于问题的认同级别，管理或领导职能发生变化。 接下来描述该矩阵中不同的区域： 1. 接近认同，接近确定性 （Close to Agreement, Close to Certainty） 2. 远离认同，接近确定性 （Far from Agreement, Close to Certainty） 3. 接近认同，远离确定性 （Close to Agreement, Far from Certainty） 4. 混乱：远离认同，远离确定性 （Anarchy: Far from Agreement, Far from Certainty） 5. 混乱的边缘 （The Edge of Chaos） 1) 接近认同，接近确定性 （Close To Agreement, Close To Certainty）
2013/12/1
articleCard.readMore改变Scrum的每日站会（Daily Scrum）-译
本文讲述了改变Scrum每日站会的一个小故事。我们从典型的以人为中心转变到以Sprint Backlog里的故事为中心。这个想法来自于Jeff Sutherland的一篇论文。 本文的目的是简要描述我们为什么和怎样进行每日站会的变化，它的优缺点，以及我们得到的反馈。在开始之前，先介绍一下背景。 背景 团队已经采用Scrum和每日站会，也有Product Owner（PO）角色。 何时何地出现了改变每日站会的需求？ 改变的需求来自于团队的回顾会议。 在改变之前，每日站会按照标准的方式进行。每个团队成员将回答3个经典问题：_1）昨天我完成了什么？2）有什么障碍？3）今天我将要完成什么？_当一个人完成后，下一个人继续。这种方式关注正在说话的每个团队成员。 几个月（许多迭代）之后，许多人抱怨每日站会效率低。基于大家对于这种效率低的原因的反思，团队达成结论，每日站会本身的这种方式可能导致了效率低。 提出什么行动计划？ 我们读过Jeff Sutherland的论文https://jeffsutherland.com/ScrumMetricsHICSS2013BWSubmissionFinal.pdf 并且非常喜欢关于改变每日站会的提议。Jeff提议在每日站会上检查Sprint Backlog中每个故事的功能，而不是每个团队成员的。作为教练，我留意到这篇论文，或许团队有兴趣学习一下。事实上，团队很高兴有这个提议，于是团队落实了行动计划，以在下一个迭代来验证这个变化。 这个改变是如何执行的？ 在接下来的迭代中，团队在相同的地方开始每日站会，但是这次是基于Sprint Backlog中的每个故事回答3个经典问题。也就是说一个以上的团队成员（取决于几个人参与这个故事）都会说围绕着具体的故事他们完成了什么，将要完成什么，是否存在障碍，以及完成这个故事还需要什么。直到手上这个故事所有相关的问题都解决了，团队才会继续进行下一个。这个流程持续到Sprint Backlog中最后一个故事讨论完。需要注意的是，建议从最重要的故事开始，按照重要性的降序继续讨论。 这个改变带来什么好处？ 假设PO参与每一次的每日站会，这个方法可以让PO听到团队关于产品开发的进展——比如，这个方法面向的是产品，而不是谁完成了什么。重要的是正在开发的产品，以及在Scrum中，团队整体执行开发工作。从概念上，我们说团队工作是一组有共同目标（愿景）的人在高度协作的环境中工作。 改变的结果是，团队的效率几乎马上得到提升。假设这是由于这样的事实导致的，当讨论故事的时候参与的每个人都发言，从而提高了专注力。相比之下，传统的每日站会经常有干扰。比如，如果两个开发人员做同一个故事，团队不得不等到两个人在不同的回合中都说完了，才能充分地理解这个故事过去和将来的行动。 更重要的是，对故事专注力的改变，需要整个团队强化正在构建产品的知识，因此现在团队专心在产品上，而不是开发人员的任务。 每个开发人员说话不做限制的事实，允许其他团队成员（他们可能在自己的故事中受阻，或只是完成了一个故事）尝试一起合作关掉正在讨论的故事，而不是去认领一个新的故事。 这个改变的缺点是什么？ 大家都知道，在接下来的回顾会议中我们分析了这样的流程改变，为了识别出优缺点。在这个案例中，观察到的主要缺点是，它很难检测到团队成员是否在工作。现在的每个站会中，讨论围绕着故事，而不是每个人在做什么。因此，团队成员必须更积极主动处理这种“闲置”的状态。 同样的，当团队成员非常忙碌的时候，可能也不是那么明显。 作为教练，假设这迫使团队需要更多更好地自组织的话，我的观点是这个缺点可以转化为机会。每个人负责有效地利用自己的时间。每个人负责查看开发流程是否停滞。而且每个人负责决定为了前行而如何一起工作。事实上，参加改变的团队发现一个方法来减轻这个缺点。比如，团队修改仪表盘，因此，查看流程中的每个团队成员的情况更容易。 关于这个改变有数据吗？ 通过调查我们收集到一些数字和指标： 团队A1有3个成员，团队A2有4个团队成员，两个团队共用一个ScrumMaster 团队B1有7个成员和1个ScrumMaster 团队C1有4个成员和1个ScrumMaster 根据上述数据，我们可以分析有多少人直接参与。总有有26个人：4个PO，18个团队成员和3个ScrumMasters。每个人的问题是：假定每日站会的这个改变，最符合下面哪条Scrum价值：_专注，勇气，或者承诺_？调查结果如下图： 我的反思 基于上面给出的数字，我想突出观察到的第一手资料，这种方式工作的团队使Scrum里面关于“团队”的概念更具体。也就是说，每个人都被真正地激励并以可持续的方式工作。每个人都认识到“集体的力量大于个人”。Scrum的目标就是尽可能早的交付高质量的产品增量。 尝试改变，观察结果，从结果中获得认知，再次改变！如果有些事搞砸了，尽早的失败比以后的失败要更重要！ 原文链接：https://www.scrumalliance.org/community/articles/2013/november/change-your-daily-scrum-meeting
2013/11/26
articleCard.readMore产品Backlog的ODDE原则与用户故事的5C原则
在写完产品Backlog与用户故事的一些原则之后，Daniel Teng同学建议补充 产品Backlog需要是ODDE的，以及user story的5C原则。 ODDE Ordered(排序的) 产品Backlog里面的条目需要是排序好的，并且每一条都是唯一序号。即代表着在产品Backlog中靠上的条目一定是比下面的条目优先级高，并值得优先开始做。 Detailed Appropriated(详略得当的) 参考前一篇中Mike Cohn提到的DEEP原则 Dynamic(动态的) 产品Backlog中的条目是动态变化的，随着项目、产品的进展，了解的深入，需要也在实时发生变化。比如说增加、删除和更新条目，或者改变条目的顺序（即优先级）。 Estimated(做过估算的) 参考前一篇中Mike Cohn提到的DEEP原则 5C 参考前一篇中Jeffries的3C，在此基础上补充2个C。并且总结为user story的生命周期。 card->conversation->confirmation->construction->consequence->card… Construction(构建) 开始构建、实现用户故事。 Consequence(结果) 实现用户故事后，可以展示的结果。
2013/11/24
articleCard.readMore产品待办事项（Product Backlog）与用户故事（User Story）的一些原则
产品Backlog 首先在Mike Cohn《Succeeding with Agile》中提到，关于产品Backlog的DEEP原则 详略得当（Detailed Appropriately） 接下来的Sprint中要完成的用户故事，需要足够的详细。而不着急开发的，则不必太详细。 做过估算的（Estimated） 产品Backlog中靠后（下）（优先级低）的事项没有充分理解（也不必），因此其估算也不如靠前（上）（优先级高）的用户故事估算精确。 涌现的（Emergent） 产品Backlog不是静止的。随着了解的深入，产品Backlog中的用户故事会增加、减少或重新排优先级。 排列优先级的（Prioritized） 产品Backlog应该根据由上至下按照条目的价值从高到低排序。团队应从中根据优先级进行开发，从而使正在开发的产品或系统价值实现最大化。 什么是用户故事？ 用户故事是一个方便的格式用来表达多种类型的产品Backlog条目，特别是特性的期望业务价值。制作用户故事的方式是让业务人员与技术人员都能理解需求。用户故事结构很简单，并且为会话提供一个很好的占位符。此外，用户故事可以在不同程度的粒度上编写以及很容易逐步细化。 3C 下面说说PB里面的形式之一，user story（Jeffries 2001），最早是Ron Jeffries在2001年提出user story需要满足3C原则： Card(卡片), Conversation(会话), Confirmation(确认). 1. 卡片： 我们并不打算用卡片去捕获组成需求的所有信息。实际上，我们故意使用有限地方的小卡片来促进用户故事简洁。卡片上应该只有几句话来捕获需求的精髓或目的。它也用作占位符以便在利益相关人、产品负责人及开发团队之间进行更细化地讨论。 2. 会话： 需求的细节是在开发团队、产品负责人及利益相关人之间的会话中暴露和沟通的。用户故事仅仅为有这个会话的一个承诺。 3. 确认： 用户故事还要包含满意条件形式的确认信息。这些是澄清期望行为的验收标准。开发团队用验收标准来更好地理解构建和测试什么，产品负责人用它来确认实现的用户故事达到他的满意。 INVEST 后来Bill Wake在2003年又总结了关于user story的INVEST原则：Independent(独立的), Negotiable(可协商的), Valuable(有价值的), Estimable(可估算的), Sized Appropriately or Small(大小合适的), Testable(可测试的). 1. 独立的： 当采用_独立_标准时，目的不是消除所有的依赖，而是用最少依赖的方式编写故事。 2. 可协商的： 故事不是预先的需求文档形式的书面合同。相反，故事是会话的占位符，在会话中细节是可协商的。 3. 有价值的： 故事需要对客户、用户或者两者都是_有价值的_。客户（或者选择者）选择并支付产品。用户实际使用产品。如果故事对他们没有价值，这个故事不应纳入产品Backlog。 _有价值的_标准的关键是从产品负责人的角度看在Backlog中所有的故事必须是有价值的（值得投资），它代表客户与用户的角度。不是所有的故事都是独立的，也不是所有的故事是完全可协商的，但所有的故事必须是有价值的。 4. 可估算的： 故事应该对设计、构建及测试它的团队可估计的。估算说明了故事的大小，因此也就说明了工作量和成本。（更大的故事比开发小的故事需要更多的努力与成本、更多的钱）。 5. 大小合适的：
2013/11/23
articleCard.readMore怎样确保想到每件事情（敏捷估算与计划）
通常有人会问，在编写产品backlog的时候产品负责人（或者团队）如何确保他们想到每件事情。这个问题对于采用合同制开发的团队尤其常见，这种开发仍然需要前期需求规范。但是我也从有些组织的团队中得到一些问题，他们喜欢不必预先锁定所有的事情。 关于这个问题我想了很多，最后我终于弄清楚了答案。当编写产品backlog的时候如何确保想到每件事情，答案就是： 等待。（题外话——等，等，还是等） 是的，一直等到项目做完。保证想清楚每件事情的唯一方法就是投入到项目中并做完，直到项目结束，随着时间准确地认识到客户想要的内容。 每个不平凡的项目都包含一些涌现的需求。这种需求提前是不知道的，但在项目中某个时间客户会想出来。不论客户或者产品负责人多么努力的去思考，项目过程中总是会有一些新的需求冒出来。这些需求是由于查看、甚至是触及正在构建的系统而造成的。看到已经开发的内容会让用户产生新想法。“现在我看到系统了，那么我想加一些新东西。” 客户和产品负责人不应把涌现需求的存在当做卑劣想法的借口。开发团队也有权利让客户和产品负责人尽力认识到他们到底想要什么。但是，就像产品负责人和客户不可能预先知道每件事一样，开发团队也需要希望他们这么做。 完全确定性是不可能的。应该避免寻求或者期待完美的确定性。 这段翻译自Mike Cohn的博客，英文版请点击
2013/11/20
articleCard.readMoreTeam Reflection
“The unexamined life is not worth living.” Socrates said. It is true as individual, however, for a team it is also applied. If a team has no inspection, they could not know where they are, and how to achieve great success. Recently I read a book named , written by Esther Derby and Diana Larsen. In this book they mention a specific structure for a team’s reflection and adaptation:
2013/11/17
articleCard.readMore《Essential Scrum》作者Kenny Rubin采访录-亚马逊最畅销敏捷项目管理书
1. 最想问不同的企业文化和价值观，以及商业定位对于敏捷的适用性有什么具体的影响？ What’s challenge for adopting agile with different company culture, core value and business? There is no one way or template to adopt Agile. No one can lead you down a predefined path that will guarantee success. Instead, you must learn, inspect, and adapt your way forward based on your organization’s own unique goals and culture and the ever-changing complex environment in which you must operate. Regardless of your adoption path, the people within the organization must have the courage to address impediments when the see them.
2013/11/13
articleCard.readMoreORID和敏捷回顾会议的结合
最近看了一下ORID，有所感悟，是否可以把ORID应用到平时Scrum的回顾会议（Retrospective）呢？答案是肯定的。 先来说明一下什么是ORID。ORID指的是提问的4个步骤，如下： [如果套用Agile Retrospective的5个过程的话, ORID缺少一个开场和收尾] _注明：[]里面代表Agile Retrospective的过程。_ [Set the Stage] Objective questions – 客观的问题[Gather Data] Reflective questions – 反应的问题[Generate Insights] [修订版]Reflective questions – 反应的问题[这个过程相当于Gather Data, 收集的是心情等主观数据 – 多谢吕毅提出宝贵意见。] Interpretive questions – 解释的问题[Generate Insights] Decisive questions – 决定的问题[Decide What to Do] [Close the Retrospective] 那么如何应用ORID到回顾会议中呢？对应以上四类问题，下面是我的一些建议： Objective questions – 客观的问题 这个Sprint我看到…… 我听到…… 发生了……事情 Reflective questions – 反应的问题 这个Sprint让我高兴/兴奋的是…… 让我吃惊的是…… 让我愤怒的是…… 让我沮丧的是…… Interpretive questions – 解释的问题 我学到了…… 我意识到了…… 这些数据告诉我们……；基于此，你的观点或洞察是…… 从中我们得到……启示 Decisive questions – 决定的问题 下个Sprint我们应该做…… 据此我们可以做……决定 最后非常感谢张树金同学做的一个关于ORID打油诗总结：
2013/11/12
articleCard.readMore爱立信精益敏捷大会总结
Linda给我的触动非常大，71岁的老太太还可以从千里之外飞过来演讲。 并且她的演讲中small success, reflection regularly都再次打动我。 从与她的聊天中得知，2011年日本刚刚地震后的一个月，Linda就去日本做了Keynote演讲，令人敬佩！ 随后她去某日本大学请教关于日本人长寿的秘诀，分享了两条给我们： No word for retirement – 活到老，干到老。退休后为兴趣而工作。 80% for every meal – 每顿饭只吃八成饱。 以下我一些流水账，以及我听的演讲中的要点： Overall: Reflect & Get inspired – Lean and Agile Conference总结 Actively contribute – sharing what I learned Network & have fun Fearless Change: Evangelist It’s about passion and learning Test the water Step by step Time for reflection Small successes What people like Feed them (do food) See things from their points of view (personal touch) Build grass roots (bottom up)
2013/10/21
articleCard.readMore敏捷之旅2013北京站招募组织者志愿者(Agile Tour)
敏捷之旅（Agile Tour）是每年一度的非营利性系列会议，旨在把敏捷社区联系起来，系列会议分别在全球众多城市召开，从10月份开始到12月份结束前后历时数月。 敏捷之旅的主要目标是： 针对敏捷的大规模交流：我们在10月份的主要任务是，开展以开发实践为主题的“大众传播”。我们希望把这些内容传递到每一个有听众的地方，从而引起人们对我们新式专业方法的大量关注。 分享我们的敏捷愿景：既然敏捷是与时俱进的，那么我们在为敏捷社区贡献我们的认识、阐释及理念的同时，要对各种新视野保持开放。 本地化增长：促进敏捷领域在世界各地的领导力。 支持：协助我们的同行及当地企业采用敏捷。 2013年，敏捷之旅已经步入第六个年头，北京的敏捷之旅活动也即将举办第四届。 敏捷之旅往届情况，请移步敏捷之旅中国官方网站。 应募条件（门槛很低的）： 身在北京 热心公益和社区活动，乐于为大家服务 具备团队精神，能够抽时间参加敏捷之旅组织者或志愿者的筹备活动，能够按时完成自己选定的任务 需要付出的： 时间 精力 金钱（这个不需要）！ 你将获得的： 活动之前和期间免费培训的机会（敏捷相关或演讲技巧） 和志同道合的朋友们一起以敏捷的方式做事，从而深刻体会敏捷理念的机会 扩展自己的人脉 扩大自己在敏捷社区中的影响力 活动当天与讲师共进晚餐，一起讨论的机会 工资（我们是公益活动，好像真没有这个）！ 组织者和志愿者的区别： 组织者需要一定的组织能力，最好能够在程序员的圈子中具备一定影响力 组织者需要平时付出更多时间和精力完成相关任务，志愿者需要付出的少一些，主要工作在现场协助组织者 组织者需要一起多多沟通，发表自己的想法和建议 其他的我还没有想到，:) 如果你对此感兴趣，很简单，发封邮件告诉我吧，我的邮箱是jiangxb@gmail.com，邮件主题为“<你的姓名> + <应募组织者或志愿者>”，正文中请包括以下内容： 姓名 公司 电话 想告诉我的话（为什么想参与到活动中啊，对敏捷之旅有什么期望啊，有什么好的建议和意见啊等等） 期待大家踊跃报名啊~~
2013/9/28
articleCard.readMore读书笔记：《驱动力》 丹尼尔平克
《驱动力》 丹尼尔 平克 作者简介： 全球50位最具影响力商业思想家之一 TED大会演讲人，美国前副总统戈尔及白宫行政部门演讲稿撰写人 《纽约时报》《哈佛商业评论》《快公司》和《连线》等知名杂志撰稿人 本书一共分为两大部分： 第一部分介绍驱动力3.0 第二部分介绍驱动力3.0的三大要素，也是本书的一个核心：自主（autonomy），专精（mastery）和目的（purpose） 本书也引用了许多试验，案例，非常推荐的一本好书。 开篇：哈利哈洛与恒河猴实验 德西与索玛立方块（Soma puzzle cube） 机械劳动（推算型工作） 创造性劳动（探索型工作） 第一章： 微软百科与维基百科的对比 驱动力1.0假设人类是生物体，挣扎求生 驱动力2.0假设人类同样会对环境中的奖励与惩罚做出回应 驱动力3.0假设人类同样有第三种驱动力——去学习，去创造，去让世界更美好的动力 第二章： 汤姆索亚效应（Sawyer Effect） 蜡烛难题（Candle Problem） 惩罚负效应实验（以色列某托儿所接孩子迟到罚款的实验） “如果-那么”型奖励 作为条件提供的奖励，比如“如果你做这个，就能得到那个”。对于重复性工作（机械劳动）来说，“如果-那么”型奖励有时会有效；对于需要创造力的脑力劳动来说，它们必定弊大于利 “既然-那么”型奖励 在任务完成后提供的奖励，比如“既然你把工作做得这么出色，我们来表示表示吧”。“既然-那么”型奖励尽管使用起来需要技巧，但它对非重复性工作（创造性劳动）的危害没有“如果-那么”型奖励大。 1. 确保内部公平和外部公平 2. 报酬要高于平均水平 3. 考核标准衡量因素要广 第三章： A型人中日摇旗呐喊，手舞足蹈，像是得了“匆忙症”，而B型人在生活中似乎很少匆匆忙忙，也不会因为自己的愿望而显得有敌意。 道格拉斯 麦格雷戈的XY理论：X型理论假设，人类会逃避努力，只为金钱和安全感工作，因此他们需要被控制。而Y型理论假设，对人类来说工作与游戏和休息一样自然，主动和创造随处可见，如果人们投身于某个目标，他们就会寻求责任。 唤醒积极性的9大策略： 1. 给自己来个心流测试 2. 首先问个大问题：“你的那句话是什么”（人生使命，愿景之类）比如亚伯拉罕林肯（他维护了统一，解放了奴隶） 3. 再问个小问题：“今天的我比昨天更优秀吗” 4. 来次施德明吧 5. 给自己做一次绩效评估 6. 不想被卡住？读张卡片吧 7. 5个步骤离专精更进一步（刻意练习，deliberate practice——为了改善在某个特定领域的成绩而进行的长达一生的努力）佛罗里达州立大学心理学教授安德斯 埃里克森提出的这一概念 1. 记住，刻意练习的目标是提高成绩 2. 重复重复再重复 3. 想方设法获得批评性意见 4. 严加关注自己的弱项 5.
2013/9/25
articleCard.readMore2012年终总结
整体印象：2012年目标完成的比较差，如下图： 我的2012总结分为以下几个方面： 健康 工作 家庭 社交 读书 其他几个方面在2012年初没有做计划，就不一一总结 健康 这一项只能打4分，2012年初体重77kg，到了现在超过80kg了。即没有达到年初的计划减肥5kg，还继续增重这么多，不可原谅啊。 分析：自从孩子回家后，体重呈现直线上升趋势。 2013： 增大运动量，尤其跑步和快走为主。 工作 工作当中主要有两大块，项目和推广敏捷。项目只能是完成预期目标，部门内推广敏捷花了比较大的力气，获得一些成果。但仍然有提高的地方。例如，工作成果没有可视化或者很好的宣传。 分析：更多的时间花在推广敏捷上，项目开发受到影响。 2013：在项目上花更多的时间。敏捷推广上要注意方式方法。 家庭 2013年是值得纪念的，可爱的宝宝今年来到我们身边。尤其是极低体重的早产儿，我的爱人和家人都付出了非常大的时间和努力。 分析：宝宝非常可爱，每天都有新变化。让我的生活丰富多彩。 2013：除了和宝宝的爱，还要更多和爱人及家庭多沟通，多一些时间相处。 社交 社交方面，今年认识了更多做敏捷的朋友，在敏捷社区也认识了更多各地的敏捷之旅组织者。 Toastmaster方面，2012投入的精力比较少，在2013需要更多的参与活动。 分析：敏捷之旅北京站的组织，给我一个非常好的锻炼机会。 2013：更积极的参与到敏捷社区活动，敏捷中国和ScrumGathering分别投稿。 读书 未能达到目标，读书20本，只读了12本。 分析：宝宝的到来，占了不少的休闲时间。使读书、学习时间也变少。 2013：新的一年，计划读书12本，集中于心理学、时间管理和敏捷相关
2013/8/27
articleCard.readMoreQcon 北京总结
QCon北京2013大会 大会时间：2013年4月25-27日 大会地点：中国·北京 国际会议中心 社交篇 这次QCon大会上，碰到很多老朋友，也认识许多新朋友。听@Shining介绍uPerform是本届QCon的赞助商，首先想到Bill Li和王宇同学。另外QClub全国协调人@柴峰同学很健谈。认识了更多thoughtworks的高人，瑶瑶，徐八叉，刘海生等等等等。 休息期间去图灵展台，认识了大名鼎鼎的谢工，以及图灵的知名编辑小花 当然还有很多InfoQ的同学们，包括Charles, Kevin, 司巧蕾, Wendy, Jesse, Floyd等 演讲篇 《胜任管理》 组织的进化——单一目标的组织（举例：不用知道事情肮脏的背后，如吃鱼香肉丝，不用知道猪是怎么养的。 组织发展面临的障碍： 等级制度 疏离感 输血文化 成功背后的幽灵 标准化培训 入职培训 团队拓展 在线学习1 结对实践 文化技能导入 定制化学习曲线 榜样的力量 学习型组织（参考第五项修炼） 建立共同愿景 团队学习1 改变心智模型 自我超越 系统思考组织的重新思考： 成员，知识工作者 任务，知识传递 度量标准，知识影响力 知识漏斗 vs 知识影响力 谜题（Mystery）vs 自我学习1 启发式探索（Heuristic）vs 自我理解 算法（Algorithm）vs 行为改变 代码（Code） vs 客户、社区影响力 读书雷达 学习验证画布 参考资料 自我介绍@QCon 有关QCon： QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。 秉承”促进软件开发领域知识与创新的传播”原则，QCon各项议题专为中高端技术人员设计，内容源于实践并面向社区。演讲嘉宾依据各重点和热点话题，分享技术趋势和最佳实践；作为主办方，InfoQ努力为参会者提供良好的学习和交流环境。
2013/8/27
articleCard.readMoreScrum的起源
Scrum丰富的历史可以追溯到1986年《哈佛商业评论》中的一篇文章《新型的新产品开发策略》（The New New Product Development Game，竹内弘高、野中郁次郎，1986）。这篇文章描述了像本田、佳能、富士施乐这样的公司是如何通过可伸缩、基于团队的并行产品开发方式开发出了世界一流的产品。文章同时强调了授权、自组织团队的重要性，并概要描述了管理在开发过程中发挥的作用。 这篇发表于1986年的文章产生了很大影响，文章中提出的很多概念都促成了我们今天称为Scrum的方法的形成。Scrum不是缩写，而是一个从橄榄球运动中借用的术语，在橄榄球运动中，这个术语指的是在意外犯规或是球出界后，重新开始比赛的一种方式。就算你不是橄榄球迷，可能也看到过争球，两队的前锋球跟前围成一圈，胳膊架在一起，低着头，争夺球权。 竹内弘高和野中郁次郎使用橄榄球和争球的隐喻描述产品开发： 产品开发那种“接力赛”的方式……可能和最快速、最灵活的目标有冲突。如果采用一种替代的方法，一种整体方法，或者叫做“橄榄球”方法——团队作为一个整体完成比赛，来回传球——能够更好地满足当今竞争的要求。 1993年，Jeff Sutherland和他在Easel公司的团队把1986年那篇文章中的概念与面向对象开发、基于经验的过程控制、迭代和增量开发、软件过程和生产率研究、复杂适应系统中的概念结合起来，创建了用于软件开发工作的Scrum过程。1995年，Ken Schwaber在OOPSLA 1995 （Schwaber 1995）上发表了第一篇关于Scrum的论文。此后，Schwaber和Sutherland，一起或是独自完成了几个关于Scrum的出版物，包括Agile Software Development with Scrum （Schwaber与Beedle，2001）、Agile Project Management with Scrum（Schwaber 2004）和《Scrum指南》（“The Scrum Guide”，Schwaber与Sutherland，2011）。 翻译自《Essential Scrum》，作者Kenny Rubin
2013/8/27
articleCard.readMore《精益创业》读书笔记
我最喜欢的一句话 成功的执行一项无意义的计划 是导致失败的致命原因 如果企业费尽心思开发出来的产品没人想要， 那么是否按时、按预算完成计划就无关紧要了。 精益创业使用来自丰田生产方式的精益思想来指导创业活动，避免在创业活动中的巨大浪费。 精益创业是一个关于“开发-测量-认知”的反馈循环，不断的开发，然后进行测试测量，得到一些认知，根据学习到的知识进行下一轮的开发。 精益创业首先有一个关于“价值的假设”，然后推出一个最小可行产品（MVP）进行假设的验证。 书里提到许多例子，比较典型的有两个： 印度乡村洗衣服务 美国最大的网上鞋店Zappos 价值假设得到验证后，下一步关于增长的假设需要得到很高的关注。书内提到传统的衡量指标（虚荣指标），有比较大的欺骗性，比如总用户数，总浏览量，总点击数。如果网站今天的总浏览量为2万，那么这些浏览量来自一个用户，还是2000个新用户呢？ 关于增长假设，书中提到两个比较好的验证方法： 同期群分析 对比测试 在各种验证假设后，得到的报告、报表中，衡量指标要符合三个“可”的标准 可执行：指标简单易懂 可使用：指标具有指导意义 可审查：数据来源可信 如果假设验证失败，那么面临一个选择，是继续坚持当前的假设，还是做出转型。如果要转型，都有哪些转型，下面是书中提到的一些转型方法： 放大转型 缩小转型 客户细分市场转型 客户需求转型 - 200多家连锁的大肚三明治（Potbelly Sandwich Shop） 1997年开办时是一家古董店。为了吸引更多顾客到店里，店主开始售卖三明治。 平台转型 商业架构转型 - 摩尔理论。公司一般会在两种主要商业架构选其一：高利润低产量；或低利润高产量。前者经常和B2B或者企业销售流程相关；后者与消费类产品相关 价值获取转型 增长引擎转型 - 病毒式、黏着式、付费式 渠道转型 技术转型 在当今的市场环境下，如果你跑的比市场慢，那么很快就会被淘汰。 所以除了验证价值假设和增长假设，还有一个很重要的关键点就是加速创业公司的发展。 公司发展大致分为三类增长引擎（模式）： 黏着式 - 客户一旦用了产品后，很难换成竞争对手的 病毒式 - 依赖现有用户的口碑宣传，影响其他人加入 付费式 - 依赖付费的方式增加新客户，比如广告 最后再介绍两个精益中比较好的理念： 小批量 五个为什么
2013/8/27
articleCard.readMore持续交付沙龙 - Jez
10月29日晚，很高兴参加了“AgileChina Salon - 持续交付” （https://event.weibo.com/636715） 这次活动邀请到了《持续交付》一书的作者， Jez Humble。 能够近距离的和大牛交流，很兴奋啊。 引子 flickr.com 每天可以发布10次以上。试想我们的软件多久可以发布。 持续交付需要频繁发布（releasing frequently） 但是频繁发布，包含哪些内容： 1. 构建正确的内容 - build the right thing 2. 降低发布风险 - reduce risk of release 3. 真正的项目进度 - real project progress 在累积流图中（CFD）， 我们通过降低batch size（WIP），达到降低lead time的目的。 但是batch size多大合适， Jez建议： 3-4天的工作量。 部署流水线，是持续交付的核心内容。 Dark launching是什么？ 发布不等于部署。 通过特性开关（feature toggle），可以讲部署好的内容进行发布，或者关闭。 很好的持续交付的资源：持续交付网站
2013/8/27
articleCard.readMore敏捷之旅2012北京站总结
敏捷之旅2012北京站总结 12月1日是忙碌的一天，也是充实的一天。这一天敏捷之旅2012北京站落下了帷幕。自从9月9日开始，在接近三个月的紧锣密鼓的筹备后，我们（组织者）有了一个完满的结果。 关于组织非盈利活动的一些个人感受： 第一要素：钱。古语，兵马未动粮草先行就是这个道理。对于非盈利活动，寻找赞助商就是这个第一要素。 设置共同的目标（vision）。这个是至关重要的，否则只是一群人在做事，而不是一个团队。（group vs team）举个例子：我们的共同目标是在12月1日办一个200人规模的敏捷之旅社区活动。 建立核心团队。 明确责任和权利。发挥团队的自组织和个人积极主动性。 尽早确定演讲嘉宾（哪怕没有确定话题，尤其是有影响力的嘉宾，可以为活动带来人气）。 宣传要在有了吸引听众内容的基础上，否则就错过了宣传的最佳效果。这一点基于上一条，需要尽早确定演讲嘉宾。 本次敏捷之旅北京站的活动要感谢 主要赞助商：OutSofting 场地赞助商：清华大学出版社 媒体支持：海丁网和InfoQ中文网 敏捷之旅北京的后续报道 报道1 - 来自mebusw的CSDN blog
2013/8/27
articleCard.readMore敏捷之旅北京活动总结 2
敏捷之旅北京的话题如下： Keynote： 段念 《生长出来的敏捷》 乔梁《小心ScrumBUT——如何让敏捷落地生根》 敏捷转型：（天） 钱安川《如何用2天交付一个项目看板工具》 杨烽熵《敏捷变革的企业战略与实施》 敏捷管理：（人） 伍斌《自动自发的敏捷团队》 唱鑫《年轻的心-敏捷实践校园行》 敏捷实践：（地） 霍金健《与CI共舞》 话题的详细细节，请猛击这里。 敏捷之旅2012北京的活动已经过去10多天了，但是一些做的好的地方一直留在我的脑袋里，现在整理一下： 提前一天的签到彩排，排除了很多异常情况（比如团队报名的如何签到；如果找不到打印的名字怎么办等应急方案） 中午发盒饭，流水线作业，参会者自动自发的排队，效率很高。 现场的路线导向，参会者很方便的找到不同的分会场。 关于作者 姜信宝 请点击这里
2013/8/27
articleCard.readMore敏捷嘉年华：抛球游戏
游戏简介： 这个游戏将要求所有参与者站立完成。大家围成一个大圈，在一个共同的标准和规则下，在既定的时间里，完成抛球的动作，达成一定的目标。然后通过每个迭代的改进，提升团队协作的效率。 我们在以往的实践中，做过几十场不同规模的团队抛球游戏。本场，我们也将向最大规模发起挑战。团队成员将能收获，较大团队的协作和持续改进，是如何完成的。 抛球游戏，是一种越来越多地被Scrum培训师采用的敏捷游戏。通过这个游戏，你可以收获： 通过迭代逐步提高工作效率 领导力是如何产生的 团队是如何学习-检视-适应 回顾的力量（reflection） 工作流（或节奏） 下面介绍游戏规则： 所有人是一个团队（大的团队） 传递的球必须有滞空时间（滞留在空气中，不能手递手） 球不能传给左右相邻的人 开始传送点=结束传送点（球从哪儿开始传递，还要回到这里才能得分） 每个迭代时间2分钟 迭代之间有1分钟的时间，大家可以讨论如何提高效率 我们一共做N个迭代（N=5） 第一次迭代之前有2分钟的准备时间 每次迭代之前，团队做一次估算 最后做总结 几个小提示： 流程- 经常团队会问“这样可以吗”？ 需要指向规则，并明确这是“团队的流程” 便签 - 如果团队有明显效率提升时，要求团队写下感受以及原因。这样可以帮助游戏最后的总结。 计时 - 注意timebox 如果团队稳定后，在最后一轮设置一个更有挑战并不可实现的目标。 反思的角度： 发生了什么？ 哪个迭代感觉最好，为什么？ 哪个迭代效率提高最大，为什么？ 反思的力量 设置不可能的目标之后，发生了什么，为什么？ 领导是如何产生的？ 有没有好的建议，但是没有被采纳？ 为什么？ 回到工作中，哪些内容可以带回去？ 参考链接：QCon Beijing 2013 敏捷嘉年华
2013/8/27
articleCard.readMore敏捷嘉年华：抛球游戏
游戏简介： 这个游戏将要求所有参与者站立完成。大家围成一个大圈，在一个共同的标准和规则下，在既定的时间里，完成抛球的动作，达成一定的目标。然后通过每个迭代的改进，提升团队协作的效率。 我们在以往的实践中，做过几十场不同规模的团队抛球游戏。本场，我们也将向最大规模发起挑战。团队成员将能收获，较大团队的协作和持续改进，是如何完成的。 抛球游戏，是一种越来越多地被Scrum培训师采用的敏捷游戏。通过这个游戏，你可以收获： 通过迭代逐步提高工作效率 领导力是如何产生的 团队是如何学习-检视-适应 回顾的力量（reflection） 工作流（或节奏） 下面介绍游戏规则： 所有人是一个团队（大的团队） 传递的球必须有滞空时间（滞留在空气中，不能手递手） 球不能传给左右相邻的人 开始传送点=结束传送点（球从哪儿开始传递，还要回到这里才能得分） 每个迭代时间2分钟 迭代之间有1分钟的时间，大家可以讨论如何提高效率 我们一共做N个迭代（N=5） 第一次迭代之前有2分钟的准备时间 每次迭代之前，团队做一次估算 最后做总结 几个小提示： 流程- 经常团队会问“这样可以吗”？ 需要指向规则，并明确这是“团队的流程” 便签 - 如果团队有明显效率提升时，要求团队写下感受以及原因。这样可以帮助游戏最后的总结。 计时 - 注意timebox 如果团队稳定后，在最后一轮设置一个更有挑战并不可实现的目标。 反思的角度： 发生了什么？ 哪个迭代感觉最好，为什么？ 哪个迭代效率提高最大，为什么？ 反思的力量 设置不可能的目标之后，发生了什么，为什么？ 领导是如何产生的？ 有没有好的建议，但是没有被采纳？ 为什么？ 回到工作中，哪些内容可以带回去？ 参考链接：QCon Beijing 2013 敏捷嘉年华
2013/8/27
articleCard.readMore通用PMBOK概念转化为敏捷概念
PMBOK基本过程组和它们对应的敏捷概念 启动过程 vs 章程（charting） PMBOK启动过程：评估项目价值（固定预算），定义初步范围（固定范围），分配资源（固定资源），以及确定时间线（固定时间）。 敏捷章程：确立愿景（共同的理解），确定目标（共享的目标），组建团队（没有承诺），以及确定时间线（固定时间）。每次迭代（里程碑）的开始重新审视愿景。 规划过程vs持续计划 PMBOK规划过程：所有计划活动（项目计划、HR、风险管理等）在项目开始已经完成。 敏捷持续计划：当有更多的信息与业务优先级改变时，计划活动发生在项目之前和贯穿始终。 执行过程vs持续交付 PMBOK执行过程：计划最终定下来后工作才开始（当前过程），利益相关者是满意的（至少这个时候）以及取得资源。 - 敏捷持续交付：贯穿项目始终计划和交付在1-4周的迭代中进行。 监控过程vs适应变化 PMBOK监控过程：为了交付固定范围的内容要严密监控时间和成本。 敏捷适应变化：时间和成本是固定的，范围基于变化的业务需求是可变的。 收尾过程vs收尾 PMBOK收尾过程：项目结束的时候得到客户与利益相关者验收的正式过程。 敏捷收尾：非正式的过程因为贯穿项目始终客户与利益相关者已经提供反馈。收尾阶段一个重要的活动是回顾。这是实现持续改进的一个关键点。 PMBOK知识领域和它们对应的敏捷概念 整合管理变成迭代计划、跟踪与管理。 范围、时间、成本管理变成固定时间与成本、可变范围。 质量管理变成持续集成、测试驱动开发、持续改进。 人力资源管理变成更关注于团队而不是个人，奖励团队的成功而不是个人的成功。 风险管理变成以迭代为基础的（比如所有计划与审查会议）整个团队参与识别、监视与分析风险的频繁反馈。 沟通管理变成经常的面对面沟通、每日站会、迭代计划与审查会议。 转载请注明来源 原文来自VersionOne
2013/8/27
articleCard.readMore什么是CSM（Certified ScrumMaster）
什么是CSM（Certified Scrum Master） CSM，即Certified ScrumMaster，是Scrum联盟发起的Scrum认证。CSM可以帮助团队正确使用Scrum，从而提高项目整体成功的可能性。CSMs深刻理解Scrum的价值观、实践以及Scrum框架。CSM是“服务型领导”，帮助Scrum团队一起紧密合作。CSM也会保护团队免受内部和外部的分心。 CSM的收益 通过获得ScrumMaster证书（CSM），您将获得： 扩展您的职业机会，尤其是在敏捷领域 展示您对Scrum知识理解的深度 学习Scrum基础，以及和最棒的Scrum专家交流ScrumMaster角色的知识 参与Scrum专家的社区 作为CSM，您有能力担任ScrumMaster。通过CSM认证过程，您可以深度理解Scrum框架，包括Scrum角色、活动和工件。 CSM认证通过后，您还将获得2年的Scrum联盟会员资格。会员可以加入当地的用户组、在线的社交网络、参加Scrum Gathering的深度折扣，以及更多的会员资料。 如何获得CSM认证（Certified Scrum Master） 为了获得CSM证书，您需要参加Scrum联盟授权培训师（即CST，作者Bob就可以发证）的线下面对面课程。 课程后参加在线的CSM考试（考试链接发到注册邮箱）。60分钟内完成50道题，答对37道即通过。（单选题） 通过考试后，需要接受CSM证书许可并完善你的Scrum联盟会员资料。 CSM认证的第一步是开始了解Scrum。Scrum联盟也准备了一系列材料，您可以进一步学习。 接着参加2天的线下课程。 在成功完成课程后，紧接着是参加在线考试，考试通过后就可以获得CSM证书。 原文链接 了解BoB Jiang
2013/7/20
articleCard.readMore什么是Certified Scrum Product Owner (CSPO)
什么是Certified Scrum Product Owner (CSPO) 简介 如果您想了解“业务方面”如何进行Scrum转型的话，那么您会渴望获得Certified Scrum产品所有者®（CSPO®）认证的合适人选。 虽然CertifiedScrumMaster®（CSM®）帮助Scrum团队共同学习和实施Scrum，但作为CSPO，您可以创建产品愿景，排序产品待办列表，并确保完成最佳工作以使客户满意。 CSPO认证的好处如下： 扩展你的职业发展机会，跨越敏捷实践的各个领域 证明你获得了Scrum的核心知识 学习Scrum的基础与产品负责人角色 与持续改进的一批敏捷从业者进行交流 除了履行产品负责人的角色外，所有新的Scrum Alliance认证持有者都可获得认证的免费两年会员资格。加入本地用户组和在线社交网络，获得对Gathering大会的大幅折扣等。 要求 上两天的CSPO课程（只有CST才能授课），最新排课计划 完成课程后，登录Scrum联盟网站，接受并同意认证的协议，完善会员信息。 维护CSPO需要获得Scrum Education Units® (SEUs)，每两年需要更新你的证书。 有关SEU信息 什么是CSM 更新你的证书 CSM/CSPO课程如何申请PDU 原文链接 行动 每日问题 你要更新CSM/CSPO/CSD证书吗，有什么问题吗？欢迎给我写信： bob@bobjiang.com 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。
2012/5/5
articleCard.readMore更新（维护）Scrum联盟的证书
更新（维护）Scrum联盟的证书 入门认证、高级认证及专家级认证 简言之， CSM证书的更新需要 $100 + 20 SEU 你为这个认证已经非常努力了。不要让它失效！立即更新并保持两年的认证。 更新CSM®，CSPO®和/或CSD®认证可以： 通过从最大、最成熟、最有影响力的敏捷认证机构获得对您的技能、知识和能力的认可，使您自己与所在领域的其他人区别开来 打开职业晋升机会与提高收入潜能的大门 参与志愿者的机会与影响Scrum的未来 持续认证路程并获得更高级的认证 展示电子证书以提升你的成就 为了验证您的参与以及对Scrum基本原则和实践持续的熟练程度，您需要通过完成教育培训或学习机会来获得Scrum教育单元®（SEU）。 这很容易做，并将帮助您保持市场的相关性（和竞争力）。 注意：所有用于更新的SEU必须在过去两（2）年内获得。 学习对于您的持续旅程至关重要，SEU是实现这一目标的简便方法。 以下是获取SEU的各种方法的示例： 注：SEU的6个分类，点击这里 - 观看社区研讨会 - 某种方式回馈敏捷社区的志愿者 - 参与本地用户组 - 参加 Global/Regional Scrum Gathering® - 写Scrum或敏捷博客 - 读有关Scrum或敏捷的书籍 下面SEU的要求从2019年2月4日起生效（更新费用不变）： 两年期的证书 需要的SEU 每期的费用 CSM®, CSPO®, or CSD® 20 $100 A-CSM ， A-CSPO 30 $175 CSP®-SM, CSP®-PO 40 $250 原文链接
2012/5/5
articleCard.readMore关于Bob Jiang | 敏捷教练 | Scrum Master
读到这里的都是铁杆粉丝，感谢你一直关注Bob同学。 Bob的系列文章 系列文章 座右铭 授人以渔（Empower People）；予人玫瑰，手有余香； 广告联盟 Bob在下面推荐几个工具（都是我自己用过且付费的），使用我的推荐我会得到返点。 tl;dv 使用AI帮你录制会议，制作会议要点，行动计划。 非常好用且功能强大的域名邮箱 FastMail 强烈推荐翻墙利器ExpressVPN，我已经用过3年多没有掉过链子。 ExpressVPN翻墙利器 Youtube油管视频制作（准备）必备工具，可以帮你选择关键词，行业。即使免费的也有很强悍的功能。Tubebuddy油管视频制作必备 价值观 正直、乐观、高效、助人 姜信宝 （Bob Jiang） CST - Certified Scrum Trainer 全球首批LeSS Friendly Scrum Trainer（LFST） 敏捷家创始人 《Scrum精髓》的译者 HiBlock区块链社区创始人人 博客 Solidity中文文档 BoB Jiang的专业证书 关注我(我的社交媒体) Telegram Group Github Youtube Twitter Facebook LinkedIn ScrumAlliance 和BoB面对面学习Scrum 微博 作品集 《Scrum精髓》 《ScrumMaster能力说明》 《Spotify大规模敏捷之路》 我的网站 Bob Jiang个人博客 敏捷家 HiBlock区块链社区 Regional ScrumGathering Scrum培训 Scrum精髓中文网站 影响地图中文网站 酷翻天 - 敏捷游戏大全 敏捷日报 敏捷变革中心 赞助 有了你的赞助，Bob会继续更新本站，以及敏捷问题集和敏捷词汇表 以太赞助：0x521aacB43d89E1b8FFD64d9eF76B0a1074dEdaF8
2011/6/4
articleCard.readMore友情链接 | Bob Jiang的朋友们
友情链接 敏捷开发学习资源大全 福强说 一个架构士的思考与沉淀 DTeam 技术日志 申导 联系我们 bob@bobjiang.com
2011/6/4
articleCard.readMore