GTD+看板方法-构建个人看板小系统

上篇文章我们提到了GTD和看板方法的异曲同工之妙,这篇文章将以“读书”为例,讲述如何在最小化的场景下使用GTD和看板的方法论,构建个人看板,以及实际操作中一些技巧。

 

这个个人看板的设计是这样的:

 

先是“收集箱”,接下来是“参考箱”,过后是“待加工”,接着是“下一步行动(<5)”,“进行中<2”,“待回顾”和“已完成”。

GTD的第一个关键行动是,就是“收集”,收集的目的在于把一切所思所想,都放入收集箱中。清空大脑,心如止水。收集箱是所有事务的入口,放入收集箱的秘诀就是快刀乱麻,只要是占用你的思维内存的任务,不用加工直接放入。[……]

继续阅读

Scrum Master成熟度模型

有人天生什么都会。无论那个行业,高手进阶之路都要过关斩将克服重重困难。Scrum Master的成长也是如此。从牛刀小试,到成为Scrum Master的终极目标 — Servant Leader(服务型领导人),这中间也像游戏里的打怪通关一样,一级一级升上去。那么一个Scrum Master的成长,到底要经历哪些级别?

与普通游戏从第一级开始修炼不同,对很多想成为Scrum Master的人来说,第一关往往是从”负”开始的。因为在以前的工作经历中,很容易积累起一些与敏捷精神和Scrum Master职责相违背的做事习惯

 

UTF8_EXCER[……]

继续阅读

在做自动化测试之前你需要知道的

 

什么是自动化测?

  做测试好几年了,真正学习和实践自动化测试一年,自我感觉这一个年中收获许多。一直想动笔写一篇文章分享自动化测试实践中的一些经验。终于决定花点时间来做这件事儿。

  首先理清自动化测试的概念,广义上来讲,自动化包括一切通过工具(程序)的方式来代替或辅助手工测试的行为都可以看做自动化,包括性能测试工具(loadrunner、jmeter),或自己所写的一段程序,用于生成1到100个测试数据。狭义上来讲,通工具记录或编写脚本的方式模拟手工测试的过程,通过回放或运行脚本来执行测试用例,从而代替人工对系统的功能进行验证。

  当然,我们更普遍的认识把“自动化测试”看做“ 基于产品或项目UI层的自动化测试”。

[……]

继续阅读

批量用户故事快速估算方法

在启动一个大项目的过程中往往需要批量估算用户故事,这是一个有挑战的过程。一方面我们不想占用太多时间,另一方面又要求具备做计划需要的准确程度(够用的准确),同时得到完整的项目范围。在众多项目中我们尝试了多种做法,来应对不同规模用户故事的估算。
UTF8_EXCERPT[……]

继续阅读

Scrum升级:Scrum + Kanban = ScrumBan

“ScrumBan”是一种周期发布过程,融合了Scrum(周期发布)和Kanban(流水线发布),是经典Scrum过程的改良成果。这种模式更适合分布式团队,更贴近实际生产流程,后续也有非常高的可拓展性。

Scrum

理想情况下,Scrum过程累积流图应该是这样的:

pastedGraphic.png

我们会筛选部分任务进入迭代清单,完成任务后,任务的点数被持续燃尽,直至迭代完成并发布。

但实际情况下的迭代过程,往往会在迭代开始时加任务,迭代临近结束时砍任务,导致在发布前夕遭遇大量瓶颈。

Kanban

在看板过程中,我们会筛选出“在制品清单”,每完成清单中的一个任务,就会新增一个新任务进[……]

继续阅读

项目成功:关注产出还是关注流程?

作为一个敏捷教练,我见证了很多公司无止境地争议同一个话题:比起项目流程,我们应该更加关注项目的产出。

以下是我个人的一些看法。我相信项目流程是一种驱动工具,如果我们勤恳的遵循流程,就可以得到预期的结果,达成既定的目标。

但我注意到,在IT领域中有两个非常常见的反面教材:

1、坚持只关注产出;

2、严格遵循流程规则,即便对于项目成功交付来说没有任何附加价值

就我看来,仅关注项目产出往往会带来重大的失误。如果我们始终只关注产出,那我们只是在思考如何“生存”,这样就会降低团队的活力,并且造成创造性思维缺失、技术债堆积和产品质量降低这些衍生后果。

现在的很多新兴企业都奉行这个观点,只要求团[……]

继续阅读