Agile

单元测试工作坊

我和Joseph一直以来想把更多的工程实践分享给更多的人,和大家一起朝着软件工匠的目标前进。一直以来我们做过Coding Dojo,Code Retreat以及Kata接力等等,现在我们想采取更直接的方式——工作坊。 我们选择单元测试作为第一次工作坊的内容。到底什么是单元测试?怎样才能写好的单元测试?如何在实际工作中写优秀的单元测试?我们将在工作坊中一起寻找答案。当然我们选择工作坊这种形式,也是贯彻我们一贯高互动的方式。不写代码如何学会写代码,这也是我们不断提高的唯一方式。不过要小心哦,我们设计了不少的坑等着你来跳。 另外我们决定这次不限制语言,所以带着你熟悉的开发环境一起来玩吧。 地址:上海浦东新区银宵路39弄(浦东世纪花园二期)3号楼1002室(Odd-e办公室) 时间:9月28日下午1:00~6:00 费用:200元/

Agile

被我们工作影响的人

上次说到我们需要一个明确的目标,那么实现目标最重要的是什么?人!人是第一要素,我们需要最先考虑的。 在实现目标的过程中,我们需要改变哪些人的行为?谁能帮助我们产生我们想要的效果?谁又会阻碍我们实现目标?谁会被我们工作影响?如果我们是在做产品,那么哪些人是客户,哪些人是用户也是需要我们想清楚的。在我们决定开始做什么功能之前,不妨先把这些问题回答一下,看看我们是否能得到一份清单。现在大多数需求都忽略了这点,大家都更多的专注于我们的软件应该做什么,而不是哪些人可以从中受益,哪些人的情况会变得更糟。 我们的祖师爷Gerald Weinberg曾经将质量定义为“对某人的价值”。如果一个功能没有给任何人带来价值,这个功能做的再华丽,再完美有什么用呢?软件不是在真空中独自运行的,它总会涉及到一些人。这些人都有各自的需要,目标和偏好。如果我们真的想要达到我们的目标,应当先考虑这些人,而不是只想着交付什么软件功能。

Agile

敏捷,传播,改变

今天微博上对Daniel的敏捷转型教导(Coaching)话题狙击手原则(iSNIPER)有很多的评论:很多人似乎觉得搞敏捷的就喜欢整一大堆的术语,不太靠谱。 这里面其实包含了三个概念:敏捷,传播,改变。我经常碰到有人认为敏捷包含这三个意思。敏捷这个词已经被用滥了。 敏捷:或者叫作敏捷软件开发,一个涵盖性术语(umbrella term),代表着一组基于迭代递增开发的方法(参考维基百科)。敏捷不过是个词而已,追究你是否“敏捷”一点意义都没有,关键在于你如何思考,如何做。如同你穿的衣服上的商标一样,管你是CK,还是班尼路。真正做敏捷的不会到处说他在做敏捷,只是说他是怎么做的,怎么思考的。 传播:

Agile

用敏捷的方式翻译敏捷经典《User Stories Applied》(三)

厄…一不小心,这最后一部分拖了这么久才写,得先自我检讨检讨。这最后的部分其实是此次翻译中最重要的一部分。这篇我将分析为什么这次翻书会比较成功。当然,这个成功的定义来自于出版社的反馈,较高的质量以及如期的交付。 首先,我们是一个分布式的团队。曾经有段时间我在美国出差,Bill也经常在国外飞来飞去,而且我们都是兼职来做这个翻译,几乎不怎么见面。那么我们是怎么解决沟通协调的问题呢? 我们使用了看板,其实也就是一个Excel表格。但是就这么简单的一个东西提供了一些项目的可见性,更重要的是它帮助我们协调任务。我们可以很容易的避免两个人做重复的任务。 每周的同步会议。从中我们可以知道,现在项目的状况。同时,大家要对未来一个星期做出commitment,即下个星期要做什么。然后是提出遇到的困难,大家一起沟通商量解决方案。其实也就是Scrum中Daily Scrum每个人要回答的三个问题。最后就是Retrospective,回顾一下我们现在项目中有什么需要改进的。

Agile

用敏捷的方式翻译敏捷经典《User Stories Applied》(二)

上次说到在我们改变翻译方式后的一个月,我们的burndown chart上的线变成水平的线,离理想的进度线越来越远,到底出了什么问题呢? 来看看我们的电子白板Excel吧 从第3章到第9章,我们确实翻译完了,也做了两次review,但是我们没有基于这些review来做修改,这并不是真正的做完了。因为需要交付时,我们并不能直接这样交付,还是得做最后的修改的。于是,紧接着的一个星期,我们就完成这7章的扫尾工作。我们终于又朝着理想线逼近啦! 但是我们依然还落后一些进度,该怎么办呢?其实仔细想想,整个翻译团队并没有发挥最大的产出。当两个翻译在翻译章节的时候,reviewer是在等待翻译好的章节,此时他们是没有产出的,直到有可审核的章节时,才有产出。如何才能利用这段时间来提高产出呢?很简单,让reviewer也做翻译。同时每个章节还是要遵守之前的约定,一个人翻译,要有另两个人来做审核。

Agile

用敏捷的方式翻译敏捷经典《User Stories Applied》(一)

数年前Mike Cohn写了这本User Stories Applied: For Agile Software Development,而我从2007年才真正开始接触敏捷,没想到2009年我有机会能够参与翻译这本有关用户故事的经典著作,我感到十分的荣幸。 这次翻译我们一共四个人参与,我和石永超(Stone)主要负责翻译,滕振宇(Daniel)和李国彪(Bill)主要负责审核,大家都是兼职来做这次翻译的。多人翻译首先考虑的是两个问题:要有个Central repository,大家可以能在上面更新或拿到最新的版本;还要有公共的标记,谁要翻译哪一章就做一个标记,避免翻译重复。既然需要一个公共的Repository,上面放的都是Word文档,我们马上就想到了Google Doc。接下来是标记问题,

Agile

Shanghai Scrum Gathering 2010

4月份又匆匆过去了,依然没怎么更新博客。这个月主要是19,20号的Scrum Gathering。这是难得的第一次官方活动。这次参加Scrum Gathering主要是三个目的: 参加一个团队的演讲,也算是给自己提升点名气吧。这次的演讲主题主要是和大家分享一下我们在翻译《用户故事与敏捷方法》过程中应用Agile的经验,希望大家跳出条条框框,不是仅仅拘泥于应用一些Agile的工具或实践。当然也要顺带宣传一下我翻译的第一本书《用户故事与敏捷方法》。毕竟Mike Cohn的这本经典经典著作居然没中文版确实有些遗憾,希望能为国内Agile做一点自己的贡献,希望更多的人能理解用户故事,理解Agile。不过对我而言,翻书过程的价值远超过这本书的价值。我的下一篇博客应该就是分享一下我翻书的经验。 来到Scrum Gathering,当然还是希望能听到新的想法,新的实践,能更加提升自己的理解。 另外就是了解一下现在国内Agile的应用到底其他公司都做的怎么样,我和我所在的公司在Agile方面到底是什么样的水平。 这两天一共3个Keynote