背景介绍

自去年起，天钥团队及区块链社区 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 之间的连接，让下一代也能接触并了解到最前沿的新兴科技，以及它们所蕴含的深意。

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. As an ambassador, you’ll help us realize this goal; you’ll help us define what it means to be a Web 3.0 project.

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. How to deal with it?

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. to list many applications from the twiiter feed.

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. act a small step.

交付还是交代

了解过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精髓》译者

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、社区、区块链、或任何有感而发的内容，要做一个每日的记录。

今日记录：回顾
行动1：每日记录文字500+
行动2：每周日回顾总结一周内容

欢迎想一起写的伙伴，我们一起每日写字。
联系BoB： bob@bobjiang.com

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 在全球范围内已得到了广泛应用：

1. 研究与确定可行的市场、技术和产品能力；

2. 开发产品和增强功能；

摘要： 本文主要描述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）是针对单个条目（如用户故事）而言的，如何验收（或确保）单个条目是满足客户要求的。验收标准具有如下的作用：

• 定义用户故事或特性的边界
• 帮助厘清客户要求
• 团队与客户（以及产品负责人）达成共同理解
• 根据验收标准可以有效的产生测试用例

验收标准的一个例子： 用户故事：
作为一个互联网银行用户，
我想要看到每日交易明细，
以便我很清楚每笔交易之后自己的账务情况。
验收标准的例子如下：

• 默认显示最近一周的每笔交易明细
• 显示当前账户余额
• 显示指定日期时间段的交易明细 ###完成的定义与验收标准

共同点

• 都是描述一个条目（特性，用户故事）是否完成的
• 都需要团队参与讨论并得出结果的

不同点

• 完成的定义是普遍性的，对每一个条目（特性，用户故事）都适用；而验收标准是具体的，只针对单个条目适用的
• 完成的定义不需要客户参与讨论制定；而验收标准可能有客户（或干系人）参与，并从中提取

建议

1. 在第一个Sprint之前，团队需要明确制定出初步的完成的定义（如果是多个团队工作在一个产品上，需要有产品级别的完成的定义）；
2. 针对每一个条目，在和产品负责人（或客户）讨论后，有明确的验收标准（AC）

针对本文的观点，您有任何建议与意见，欢迎与BoB取得联系。
BoB at c4at.cn

引言

敏捷火热，随之出现很多敏捷热词，比如敏捷组织、敏捷营销、敏捷管理、敏捷blah blah。在这么多敏捷词汇背后，映射出敏捷已经受到越来越多的行业与人群的关注。然而就在我们日常工作的组织中，有很多与敏捷相悖的陷阱（或常识）。这里和大家分享如下几个：

• 跨地域团队
• 狂热的敏捷
• 外包客户服务
• 大规模敏捷的困扰
• SAFe or safe

跨地域团队

软件开发工作，没什么比得上大家坐在一起更高效了。 “通讯基本靠吼，交通基本靠走”，虽然这只是一句顺口溜，然而放在软件开发工作中是非常贴切的。 我想要寻求某个问题的答案时，只要站起来走到同事身边，吼一下就可以了。 现代移动互联网时代，越来越多的工具尝试代替人与人之间的沟通，比如Skype, Slack, Trello, Teambition, Leangoo,等等。发个消息过去之后，就如石沉大海没有了回应。这是一种什么心情呀。 因此，对于软件开发工作不要跨地域团队。（注：这里的地域可以大到国家，小到楼层）

狂热的敏捷

组织敏捷转型催生了对于敏捷培训师、引导者以及咨询师的大量需求。很自然地出现了求大于供。这种情况下就会出现一些浑水摸鱼的人，来满足企业和组织的需求。如果雇佣了一名知识与经验不足的敏捷咨询师，组织很快就会对于敏捷失望透顶，失去兴趣。那么以后再想重整旗鼓就很难了。 因此选择靠谱的敏捷培训师、咨询师是很重要的第一步。

外包客户服务

如果你和客户之间没有直接的链接，那么你将失去创新的机会。你也就不会得知客户真正想要什么。很不幸的是，很多组织在缩减成本，往往会把与客户直接对话的客服部门进行外包。 停止外包你的客户服务工作吧！

大规模敏捷的困扰

我不相信有一个完美的框架，可以帮助组织很好的实现大规模敏捷。以前没有，以后也不会有。盲目地相信有这种解决方案的人，是懒惰的，是想逃避责任的。 在选择或实施大规模敏捷之前，需要问以下问题：

• 为什么要采用大规模敏捷
• 想要解决的组织问题是什么

SAFe还是safe

SAFe是一种以价值流为核心的大规模敏捷方法。组织因此可能变得更高效或以客户为中心。但很多企业选择SAFe的时候并不理解敏捷宣言，不理解敏捷的价值观。寄希望于一套完整的框架方法可以帮助组织进行整体一次性的转型。SAFe方法提供了一套完美的完整的框架（包含原则、方法、实践），给高层领导者一种很安全（safe）的感觉。然后组织根据自己的情况进行裁剪与适应。 在转型的初期，这是奏效的。然而随着时间的推移，转型的深入，这种方法很可能无法完全适应组织的需求。因为SAFe并不提及组织结构的改变。 而企业或组织的核心是盈利，是需要完成产品开发。另外一种大规模敏捷方法LeSS，是以产品为核心，特性团队（组织结构的变化）为基础，以系统思考、精益思想等为原则的框架。

想要大规模敏捷，除了问下上述的两个问题，更多要全局思考。 有关LeSS更新信息请参考