重复的劳动。 一项功能时,你需要手工打开网页,然后按着流程一步一步操作,来看实现是否正确等。每 当此时,我们的选择是:绝
不做简单重复的劳动,而是实现一个自 动化的脚本来帮助我们 进行这些操作。自动化不同的任务,可以选择不同的工具,比如 Selenium、Ruby、Shell 等等。后来我在《The Productive Programmer》中读到 Neal Ford 大师如是说:“手工执 行简单重复的任务会让你变傻,会消耗你的注意力,而注意力是最重要的生产力之源。找出 一种聪明的方法来自动化这些任务,这会 让你变得聪明,因为你能从中学到一些东西。” 每天早上的 code diff: 在早晨的站立会议结束后,我们并没有马上着 手清扫 story。所 : 有开发人员会挤在一台机器前,查看前一天的 code diff。大家会看到所有成员在前一天的 工作中修改的代码, 相关的开发人员会对自己的代码作出解释。 当有人对一段修改有疑问时, 我们就会对此段代码进行讨 论。或者是实现上的一些逻辑漏洞,或者是一些不规范的代码
编写,或者是一些可能的性能改进,我们总能对一些代码提出疑问,并提出改进意见。Cod e diff 过程是对站立会议以及结对编程的补充,是对代码质量的进一步检验,有助于团队对 代码的了解,也促进了代码质量的提升。短短十分钟,何乐而不为? 每周的技术 session: 每 周的技术 session 是我们一直保持的良好传统,团队从中受益匪 : 浅。项目中总会遇到一些难题,或许是一种陌生的技术,或许是一个难解的问题。而此时, 总 会有人站出来说:“让我来讲讲这个吧”。或许这项技术对于主持者也是完全陌生的,但 不要紧,接下来一周紧张的学习已经足够(这也会促使他更加快速地学 习)。一周之后, 主持者就为我们带来了一道“丰盛的大餐”。在 session 中,团队成员都会踊跃发言,并乐于 抛出任何疑问让大家讨论。讨论是最能产生火 花的,来自每个人不同的思考会让你对问题 了解得更加深刻。讨论帮助我们解开了一些困扰已久的疑问,并加深了对一些技术的理解, 比如:CSS,Memory Cache, REST, Ajax,Ruby 的对象模型等等。通过技术的讨论和学习, 团队成员的整体开发能力得到了提升,这极大地促进了项目的开发速度。 团队需要勇于尝试一些实践来促进团队的开发效率和提升团队的整体能力。 上面所提及的有 些实践都是我们在平时的工作中摸索、体会和总结出来的。比如每周的技术 session,就是 在成功地开展了一次之后,被保留和坚持下来了。 如何发现一些值得尝试的实践?这看似很难,其实很简单。在项目中遇到的问题,工作中偶 然发现的一些事情,别人的经验,或者是你自己的一些想法,都可能是对一项实践的启发。 你唯一要做的,就是勇于尝试。“从来没有人这么
做过”,或者“别人都不这么做”不是你不这 么做的理由。 TimeMachine.go_to("2008-08-01") 当项目开发进入第 5 个月,我们遇到了一些真正的困难,它们分别是“历史”story 和系统性 能优化问题。 当项目遇到困难时,正是审视敏捷实践的最好机会。TDD,简单设计,持续集成,重构等等, 让我们看看这些实践在项目开发中显现的力量吧。 笑看历史——关键字:简单设计,TDD(测试驱动设计) 关键字:简单设计, 笑看历史 关键字 (测试驱动设计) 历史 story:作为 全球质量管理员,我要 查看一个酒店的标准审查历史记录,从而 跟踪并 作为 我要 从而 比较酒店在各个时期的标准符合度。 简单分解一下这个 story,它要求提供的功能是: ● 系统在一些比如标准变化、酒店审核等事件发生时能保存当时的数据。 ● 系统应该提供一个界面,让用户通过选择特定的日期查看历史信息。 跟通常一样,我们经过 estimation(当时估的是 5 个 points,并不太大)以及 tasking(简 单的设计)之后,开始实现这个 story。
刚 开始,这个 story 如预期一样顺利开发下去了。一天,两天,到了第三天,我们突然发 现在实现一些功能时有点举步维艰。但通过一些“邪恶”的手段,我们还 是解决了那些问题, 虽然觉得并不是最佳实现。到了第四天,在实现另一些功能时,我们陷入了绝境:实现得过 于复杂让代码改动极其困难,通过了这边的测试,那 边的测试就失败了,如此反复。还差 两天迭代就要结束了,这个 story 却深陷泥沼,团队陷入担忧之中。我们决定重新跳出来看 一下原来的设计。 基 于实现中遇到的困难,我们讨论了原先的设计,发现一些缺陷,并迅速找到了更好的方 案。新设计雏形初具,再次动手吧。改动代码,很多原先的测试应声失败了。 好事情,失 败的测试告诉我们哪里出了问题,过去修正那些失败的测试吧。红,绿,红,绿,按照这样 的节奏,出乎所有人意料的事情发生了:一个下午,仅仅是一 个下午,我们把历史 story 完成了! 因为这个设计并不在技术层面,而在业务层面,所以在这里我并不想多讲 story 的详情。但 发生这样的问题,是否会让你怀疑敏捷实践“简单设计”呢?如果你有此怀疑,我的想法就正 好跟你相反,因为通过这个 story 让我更加相信“简单设计”的好处。 首 先,即使现在回