剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 Mark Levison译者 郑柯 发布于 2008年3月6日 下午7时39分
David Longstreet将自己视为“一个软件经济学家和国际咨询师”,去年他撰写了一篇论文宣称“敏捷软件开发”是一个童话,它只是试图将“牛仔式”开发正统化的一种方式。Maverick软件开发模型的作者Geof Slinker,使用逻辑论据来展示David思考中的错漏之处,并邀请他以更严格的方式再次论证他自己的观点。
下面这段文字来自David Longstreet于2007年发表的文章[链接为pdf格式]:
到目前为止,软件开发仍然是一种类似于早年美国西部拓荒式的活动。
IT部门及其人员一直都很懒散。Agile也没有什么新鲜的,因为它不过是试图将懒散的活动正式化。
Geoff Slinker使用了逻辑论据来 指出David思考中的纰漏。Geoff早年也跟David一样,对XP持有怀疑态度,甚至着手要写一篇揭露XP缺点的论文。然而,开始深入研究XP之 后,他逐渐认识到了其中的价值并开始在自己的项目中应用相关实践。针对David声称Agile是要将懒散正统化的指责,Geoff反驳说使用这样一个充 满漏洞的论据简直就是自取其辱。
David声称Agile不重视需求和文档规范。Geoff通过David对Agile中用户故事的描述来反击他:
(David)先生在讨论结对编程时说到:“结对编程就是:一个程序员写代码,另一个程序员站在他背后观察错误。”
这完全是错误的。他接着说:“我不知道结对编程要解决什么问题。软件开发中的绝大多数问题都与不完整的需求相关,跟编码没多少关系。”
要推翻他所说的关于结对编程的第一部分易如反掌。而且他关于绝大部分问题都与不完整的需求相关这个观点,也是混淆了因果关系,而且这也犯了“想象结果论证”[译注1]的错误。
David还说:
软件开发面临的最大问题就是需求不完整。我琢磨着对于敏捷人士来说,花费更多时间在编码而不是整理需求或者编写清晰的需求之上,是唯一合理的选择。
Geoff指出这也是混淆了因果关系,并在结尾邀请David基于正确的逻辑和引用来源再写一篇文章来向敏捷方法发起挑战。
译注1:想象结果论证:appeal to consequences,是指通过说明某种主张在个人的想法或是信仰中所造成的影响与结果,来论证这种主张是否成立的一种谬误。
查看英文原文:Bedtime User Stories: Cowboys and Fairytales
本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目,怎样配置一个JSF应用去使用JBoss Portlet Bridge,以及JBoss Portlet Bridge所具备的功能。
在这篇文章里,Bryon Jacob和Chris Berry将和我们继续探讨AtomServer,它是基于Apache Abdera的完整Atom存储实现。作者还创建了几个Atompub规范扩展,其中包括自动标记、批处理和Feeds聚合。
InfoQ中文站的电子杂志《架构师》试刊第二期出版了!相比于上期,我们在内容的选择安排和版式上都根据读者的意见重新做了修正。“细节决定成败”,我们希望基于InfoQ中文站的专业内容,《架构师》能逐渐成为大家喜欢的电子刊物!
在本文中,Steven Haines探讨了Web应用性能调优问题。该领域过去更像是一门艺术而不是一门科学。他提出了一种称为基于等待调优的方法,使整个调优过程更加可度量,也因此更具科学性。
通常来说,改变技术路线时最艰难的部分是辨别语言语法之间的不同。这篇文章就为Java开发者提供了一份如何转向Flex基础语言ActionScript的指南。
本视频主要以财帮子为例,介绍了如何创建一个PV为百万级的Rails应用。其中包括:Rails应用的服务器架构、Rails Cache的优化、负载均衡的处理、Web服务器的调试、分布式解决方案、Open API的设计等等。
InfoQ首席架构师Alexandru Popescu在采访中谈论了InfoQ架构、Webwork与DWR、Hibernate与JCR、Hibernate可扩展性、最新的InfoQ视频流系统和InfoQ的未来规划。
2 条回复
回复