-
编辑 删除
从结对编程到结对工作
熟悉极限编程的人都知道，在极限编程的十二项实践中，有一个非常重要的实践就是结对编程，也就是两个人坐在同一台电脑前面，使用相同的键盘和鼠标来开发同样的一个模块，一个负责代码的键入，另外一个人负责盯紧可能...
-
编辑 删除
UML在活塞PDM系统建模中的运用
1、引 言Web技术的发展，使得管理系统的开发更方便、功能更强大，在此系统的开发过程中，Web技术起了一个骨架式的支持作用；与此同时组件技术的发展为系统的开放性、集成性提供了便利，有效合理地引入组件技术是当...
-
编辑 删除
关于Peer Review、代码评审和测试驱动
关于Peer Review，中文不知道应该怎样翻译才贴切，一些人翻译作“同行评审”，一些翻译作“对等评审”，我现在姑且意译作“成员间相互检查代码”。Peer Review实际上在外国已经流行n久了，...
-
编辑 删除
RFactor：为文本编辑器提供Ruby重构支持
RFactor是一个Ruby gem，旨在为人们最喜欢的文本编辑器提供自动化重构的支持。可我们不是有IED支持重构么？这倒没错，不过RFactor的开发者Fabio Kung坚信，“大多数Ruby开发人员都没用IDE”，文本编辑器已经够...
-
编辑 删除
拥抱变化的极限编程
XP是与众不同的，它具有快节奏、高效率、轻量等鲜明特点。其开发过程包括许多的小卡片，独立的看，这些小卡片没有什么意义，但是当它们组合在一起，就可以看见一幅完整的美丽的图片。 极限编程（Extreme Pr...
-
编辑 删除
敏捷开发中重构的秘密
一提到重构(Refactoring),先不给出重构的定义,我们根据字面意思猜想,重构大概就是要重写代码。 的确,单从字面上理解,重构与重写代码非常相似,但是,细纠起来他们却有着本质的区别。下面我们就以重写代码为切入点,重点...
-
编辑 删除
将传统软件开发的角色映射到Scrum中
多着手实施敏捷的组织，都不得不把传统软件开发的角色与 Scrum定义的三种角色 之间的映射处理好。传统的角色如：产品经理、项目经理、业务分析师、设计师、DBA等等，在Scrum中没有清晰的映射关系。Mike Cottmeyer 在...
-
编辑 删除
三项执行层的支持，支撑起敏捷实施的天空
除了决定要用敏捷并为培训买单之外，接下来执行层的工作还有不少。要想让这个改造成功，执行层必须要一直提供支持。Esther Derby从在这些支持中选出了三项她觉得最重要的工作。她在Agile Journal写了一篇文章：三项...
-
编辑 删除
37 Signals的实用最小主义实践
尽管有那些可能性——复杂度、延误和不可预知的改动——还是有许多软件写出来、交付出去、而且最终被使用。偶尔软件会很好。在一些罕见情形下，软件的确有创新和价值。在一些案例中，还真按计划达成了目标。在这些...
-
编辑 删除
应对敏捷项目中的干扰
干扰，正如它名字所显示的，是影响敏捷项目团队速度、减缓其前进的刹车闸。有些干扰是必需的，其他则不是。关键在于：要识别出影响工作进程的干扰，并尽量减少它对项目的负面影响。 Extreme Programming讨论组...
-
编辑 删除
将测试人员整合到敏捷团队中
将测试人员整合到敏捷团队中，这是敏捷之道常常重复的一条箴言，可我们并没有认真想过这到底意味着什么或者应该怎么做。 团队中测试人员的角色具体负责什么呢？他们要： 协助团队抽取并定义验收条件（或需求） ...
-
编辑 删除
每日站立会议怎么开？
在那些最简单也最常谈起的敏捷实践中，每日站立会议（又称作每日例会）就是其一。Jeff Martin 在scrumdevelopment Yahoo! 邮件组中问道：我搜索过相关知识却一无所获，我想我一定是用错了词。谁能给我一个每日例...
-
编辑 删除
创建适于敏捷的组织文化
Greg Smith在一篇文章（内容源自他即将出版的新书《Becoming Agile》）中提出观点认为，要全面深入并务实地过渡到敏捷模式，关注文化变化的重要性不亚于对流程改变的关注 。在众多讲述各种敏捷方法论（尤其是极限编...
-
编辑 删除
Mike Cohn的“走向敏捷”三模式
敏捷联盟创始人之一、咨询师兼图书作者Mike Cohn最近根据其自身经验将“如何帮助团队采纳敏捷”总结为三对核心模式，当团队向敏捷过渡时，可以利用这些模式。Mike建议，团队或者组织在逐步采用敏捷的过程中，应该从...
-
编辑 删除
为敏捷团队准备的Lisp
Paragent是一个基于web的、开源的IT管理系统，它的开发语言是，是……Common Lisp？在他们最新的blog里面，Paragent的开发人员描述了他们使用Lisp的经验： 在开发新的服务器控件时，除了对Ruby/Rails、PHP和Python...
-
编辑 删除
将程序记在脑子里
最近，在一篇名为《将程序记在脑子里》的文章中，Paul Graham认为“代码就是你对某个问题的理解。所以，只有当你把代码牢记在脑子里，才算真正地理解问题“。不幸的是，正如每个程序员所知，说起来容易做起来难： ...
-
编辑 删除
提高软件开发生产力的秘方
专业训练者和导师们一再发现：许多敏捷团队囿于同一种模式的困扰——在平庸的“照本宣科（Norming）”阶段一直徘徊，团队的成长始终没法进步到令人兴奋的“大放光彩（Performing）”的阶段[1]。我们请读者来一起思考...
-
编辑 删除
用了敏捷实践就是敏捷项目吗？
采用敏捷方法学的人正在逐渐增多，在最近的调查中显示，XP，Scrum和FDD这些方法被广泛使用，已经达到了前所未有的程度。但其中也有反面教材——如果开发团队只是简单的把敏捷实践拷贝到项目中而不是在实践中逐步掌握...
-
编辑 删除
培养敏捷态度
关于敏捷方法论的文章已经很多了。其中，相当一部分文章讲述了敏捷方法技术方面的问题，比如测试驱动开发和持续集成。同样，还有相当一部分文章讨论了敏捷 方法论的应用问题，例如发布计划，跟踪生产率，如何使用度...
-
编辑 删除
敏捷的核心：消除浪费，走向精益
敏捷的核心是什么？敏捷给软件企业（以及软件开发者个人）带来的好处究竟在哪里？这个问题有很多不同的答案。例如“重视个人和交流”，软件开发者喜欢这样的态度，这是毫无疑问的。例如“重视可工作的软件”，它的价...
