《敏捷革命》读书笔记

Fri 15 February 2019

基本过程

准备

  1. 挑选一位 产品负责人(Product Owner) :负责沟通客户并根据客户反馈规划待办事项
  2. 挑选 团队 :小而精,3 ~ 9 人
  3. 挑选 Scrum 主管(Scrum Master) :培训 Scrum 确保 Scrum 正确运用,消除团队障碍
  4. 确定 冲刺(Sprint) 周期,不要超过一个月,最好 1 ~ 2 周

执行

  1. 产品负责人拟定 待办事项 ,并确定优先级

  2. 让实际开发的团队评估和改进待办事项

  3. 通过 冲刺规划会 规划接下来一个冲刺要完成的待办事项,并将借助 看板 工具将工作透明化

    看板可分为如下几个项:

    1. To do -- 当前冲刺需要完成的任务
    2. In progress -- 当前冲刺正在进行的任务
    3. Done -- 当前冲刺已经完成的任务
  4. 冲刺开始后需要进行 每日站会 ,时间不应高过 15 分钟,Scrum 主管向团队成员提出下列问题

    1. 距离上次站会之后到现在你做了什么去帮助团队完成冲刺
    2. 距离现在到下次站会之前你打算做什么去帮助团队完成冲刺
    3. 什么因素阻碍了团队完成冲刺

    站会应在每天的固定时间点,团队所有成员必须准点参加。

  5. 每次冲刺结束之前展示 冲刺成果 ,面向展示的对象主要包括:利益相关者、管理人员与客户

回顾

每次冲刺结束之后下一个冲刺开始之前要举行 冲刺回顾会议 ,会议主要讨论以下内容:

  • 展示之前冲刺中创造的成果
  • 总结冲刺中哪些做的好,哪些需要做的更好,找出真正的障碍并拿出勇气将障碍摆在台面上
  • 确定一个最值得改善的地方,将其设定为下一个冲刺的首要任务(关键)
  • 计算快乐指标(见下文量化快乐)

下一个冲刺

上一个冲刺结束后,立即开始新的冲刺。

辅助工具

传达的理念

节奏

Scrum 流程的核心是节奏,每天准点的站会,固定周期的冲刺,冲刺之后的回顾都将我们带入一种节奏中。

守破离

要先学习规则和形式,掌握之后再进行创新,最终摆脱规则和形式。

强调团队而非个人

  • 拒绝产生英雄式人物,如果一个团队的领导者在休假时还要确保办公室一切正常,那么就说明他没有管理好自己的团队
  • 能够自主决策,最大化地提升人的自由、能力和创造力。
  • 不为失败指责他人,客观的找出问题整个团队一起完善
  • 强调团队绩效而非个人绩效

拒绝浪费

  • 鉴于人类单线程生物,不要同时执行多项任务,会浪费精力导致最终所有事情都做不好 -- 同时执行多项任务会让你变的愚蠢
  • 如果事情做到一半就放弃了等同与什么也没做 -- 半途而废等于没做
  • 应该一边做一边测试,并及时改正测试出来的错误,而不是等整个产品成型后再交付测试导致返工造成浪费 -- 一次性把事情做好
  • 延长工时不会提高效率,反而会陷入恶性循环,造成浪费

评估使用点数替换时间

传统的项目排期会评估某个任务的截止时间或者所需时长,但是在敏捷中应该评估任务的点数,并有以下几个要点:

  • 点数不使用常规的顺序的数字,而是使用 斐波那契数列(黄金分割数列) ,好处就是可以明确的分辨不同点数之间的差异,考虑如下两列数列的差异

    正常顺序 斐波那契
    1 2
    2 3
    3 5
    4 8
    5 13

    斐波那契数列能更好分辨不同级别的点数之间的差异,如 13 和 8 之间的差异,就比 5 和 4 之间的差异要好分辨的多。

  • 采用类似 德尔菲法 的方式评估任务点数,避免相互影响

    方法是类似打扑克牌的方式进行评估

    1. 参与评估每个人都拥有 2 3 5 8 13 这 5 张牌
    2. 对每一个需要评估的任务所有人都给出自己的点数但不公开
    3. 所有人都评估完成后给出点数
    4. 得出结果,有以下几种情况
      1. 所有人点数相近,取平均值
      2. 差距较大的情况下,找出差距最大的两人分别阐述原因,然后重新出牌,直到点数相近,取平均值

    因为人类本身就有从众的缺点,并且很容易受 光环效应 的影响导致判断偏差,采用这种方法评估能很好的规避这些缺点。

以此评估就可以统计出每个冲刺完成的任务点数,实践 Scrum 后团队完成的点数会在初期成倍增加。

免费更换需求

需求可以免费更换,这里免费指对客户免费,在自有产品中可以换成自由更换,但自由更换并不代表没有代价,要从已经安排进去的待办事项中替换相同点数的事项。

快乐是第一生产力

这里的快乐是指可以让团队提高效率的快乐,而非享乐的快乐,比如

  • 提高团队运作的透明度,不应该有秘密小集团、秘密日程和其他什么秘而不宣的事情
  • 给予团队中的每个人自主权,让每个人都受到尊重
  • 承认只有糟糕的制度没有糟糕的团队
  • 团队成员之间相互信任,踢出让其他人不快乐的成员等等
  • 扁平化
  • 增强团队成员之间的联系(羁绊的力量)

这里要避免经过一段时间的进步之后安于现状,要有“聪明的傻瓜”勇于刺破“快乐的泡沫”。

量化快乐

在每次冲刺结束后应统计成员的快乐指标,参与冲刺的每位成员都需要回答以下 4 个问题

  • 你对自己在公司的角色感觉如何?请以 1 ~ 5 分加以评价
  • 你对公司整体情况感觉如何?请以 1 ~ 5 分加以评价
  • 为什么会有这种感受?
  • 在下一个冲刺阶段中,什么事情会让你感到更快乐?

通过计算评价分可以得出整个团队平均快乐指标。

MVP 最简化可行产品

  • 一个产品 80% 的价值来自 20% 的功能
  • 产品负责人列出待办事项并找出其中对用户最有价值的
  • 及时犯错:有些错误早犯可以尽量减少给别人造成的伤害,而且以后也可以想办法避免

总结

本书引用大量的实践 Scrum 的团队的经历和研究结果,来阐述敏捷的力量。同时也通过大量的例子表明 Scrum 不仅仅可以用在软件开发,同时也适用于教育、政府、金融等其他行业。 总之说服力(洗脑效果)非常强。

Category: 读书 Tagged: Scrum Agile 敏捷 阅读

comments


通过 acme.sh 获取 Let's Encrypt 免费证书

Tue 12 February 2019

配置 Nginx 正确处理 Webroot 验证

在证书签发过程中 Let's Encrypt 会验证你拥有当前域名,最基本的方式在你的网站根目录创建一个文件,并通过域名在外部进行请求,如能请求到则认为你拥有该网站的控制权。假设你有一个域名 example.com, 验证步骤大体如下:

  1. 通过工具在网站根目录下创建 .well-known/acme-challenge/some-random-letters
  2. 工具将创建的路径告知 Let's Encrypt
  3. Let's Encrypt 通过域名请求该文件,如 http://example.com/.well-known/acme-challenge/some-random-letters
  4. 若能请求到则确认拥有该网站的控制权颁发证书,否则拒绝颁发

为了简化多个域名颁发证书需指定不同的 Webroot,我们可以将所有域名的验证统一放在一个目录下,并新增一个配置片段供需要启用 HTTPS 的网站引用,新增 /etc/nginx/snippets/letsencrypt-acme-challenge.conf ,并填充如下内容

#############################################################################
# Configuration file …

Category: Linux Tagged: SSL HTTPS

comments

Read More

修改本地 Git 历史

Wed 21 November 2018

很早之前一篇发表在内部的文章,抽时间整理了一下发布出来。

以下操作会修改提交历史, 可能会造成一些不可恢复的问题, 不是 下面情况不要这么操作

  1. 基于 GitHub Fork -> Pull Request 流程仅针对 Fork 后的仓库进行操作
  2. 非第一种情况的前提是当前修改的提交还未提交到远端

操作下面命令前最好先备份

修改上一条提交的信息

有时候我们在用 Git 提交后发现提交信息(commit message)不是我们预期的内容(错别字或描述错误等), 这个时候我们可能想修改一下上一条提交的信息, 有两种方式可以进行:

$ git commit --amend

这条命令会直接打开你的终端编辑器让你可以修改提交信息, 也可以组合 reset 命令重新提交:

$ git reset HEAD^ --soft
$ git commit -m 'new message'

这条命令会撤销上一条提交, 并将上一条提交的内容放在工作区内(git add 之后的区域), 然后就可以通过 git commit …

Category: Git Tagged: Git

comments

Read More

通过 pyenv 在生产环境安装 Python 3

Wed 21 November 2018

pyenv 是一个简单的 Python 版本管理, 可以安装对应版本的 Python 不依赖系统的包管理, 我用它来在生产和测试环境安装 Python 3.6.

它的基本原理是安装对应版本的 Python 在它自己的目录下, 然后将对应的 bin 目录通过插入 PATH 变量里实现.

安装可以参考官方文档, 但是用它部署 安装在 HOME 目录下会引起一些权限问题, 所以我将安装目录放在了 /srv/pyenv 下:

$ git clone https://github.com/pyenv/pyenv.git /srv/pyenv
$ echo 'export PYENV_ROOT="/srv/pyenv"' >> ~/.bash_profile
$ echo 'export PATH="$PYENV_ROOT/bin …

Category: Python Tagged: Python 2to3

comments

Read More

解决 macOS 下安装 pycurl 后导入错误

Tue 20 November 2018

在 macOS 下安装 PycURL 后 import curl 会提示:

ImportError: pycurl: libcurl link-time version (7.43.0) is older than compile-time version (7.49.1)

这是因为系统中的 curl 版本过老导致, 可以通过使用 Homebrew 安装最新版来解决:

$ brew install curl

安装完成后会提示一些信息, 按照提示的信息将 curl 加入到 PATH 路径, 参考:

$ echo 'export PATH="/usr/local/opt/curl/bin …

Category: Python Tagged: pycurl macOS OSX

comments

Read More

从单一软件到处处实践 GTD

Sun 05 August 2018

这篇文章首发于我们团队内部。

刚开始接触 GTD 时我是找了一个软件来实践 GTD, 但是效果不是特别好,主要三点:

  1. 收集麻烦
  2. 需要单独的软件,我一般会为了节省资源尽量少开软件的的人,所以我对打开很多的软件会很不爽
  3. 最主要是懒

所以后来我就开始慢慢放弃收集,再也不打开那个软件。再接着我发现其实我们所用到的很多软件都帮我们已经实现了类似的机制。下面举几个我用来实践 GTD 的地方。

邮箱

大部分情况下如果别人让我做一件事我会让 Ta 给我发一封邮件,如果我没有完成邮件中的工作那这封邮件就会一直在收件箱里躺着, 直到我完成了对应的工作我就会选择将之归档或移动到特定的文件夹,所以我目前有上万封邮件但是收件箱里只有少数没有完成的邮件。

每天我打开邮件看到收件箱我就知道哪些还没有做。

禅道

我们内部使用禅道做项目管理和 Bug 跟踪,测试和产品会指派给我们一些 Bug 或需求,我们没有完成就会一直在我们名下。 但是有一点是需要注意的就是我们一旦完成(或者说接下来需要他人处理)那么就需要及时变更状态, 这样就可以推动别人来继续。

不要把不属于自己的部分放在自己名下。

GitLab

GitLab 右上角有一个 TODO 的通知,一般我没有完成的我是不会点击完成(Done)的。比如今天有一个发送周报的 Issue 提醒 …

Category: 效率 Tagged: GTD 高效

comments

Read More

迁移到 Python 3

Thu 13 July 2017

前段时间(2017-06-07)我开始决定将公司现有的项目逐渐的迁移到 Python 3. 主要原因有一下几点:

促成我决定迁移到 Python 3 的主要原因是公司最大的项目的单元测试覆盖率经过一段时间的迭代终于达到了 80% 以上.

迁移方案

由于项目巨大任务艰巨无法短时间内就将项目迁移到 Python 3, 而且当前还有产品上的功能需要迭代. 所以迁移方案是同时兼容 Python 2 和 3, 并在迁移完成之后移除对 Python …

Category: Python Tagged: 2to3

comments

Read More
Page 1 of 11

Next »

Fork me on GitHub