最后期限,解开最后期限的镣铐
最后期限（Deadline）是软件从业人员必须面临的最大困难与挑战，准确地说，它是所有程序员包括项目管理者的可怕梦魇。当堂吉珂德看到郊野之上的数十架风车，风车的翅翼如巨人的胳膊，正耀武扬威地奚落着这位中世纪后期没落的骑士时，堂吉珂德如勇敢的斗士一般，跃马而上，用长枪狠狠地刺向风车，换来的却是长枪折断，人仰马翻，最后大败而归。没错，最后期限之于程序员，正如风车之于堂吉珂德，确实是太强大以至于无法战胜... [阅读全文]
结对编程,什么时候该采用结对编程?
结对编程是构建软件系统的一种有效方法。采用结对编程，带来的显著效益： 更好的想法——持续不断的头脑风暴、更大的知识库、在理解上有更少的差异、有更多的脑力解决设计问题； 更好的质量——更少的漏洞、想法的即时认证、始终如一的方法并更加遵守团队会议中的要求； 更全面的认识——经验共享与知识共享、对于为什么做、怎么做和做... [阅读全文]
软件开发生命周期,软件开发生命周期中的安全性
我们必须把应用程序的安全性整合到软件开发的过程中。之后在测试中才关注安全性是不够的，因为对于修改错误来说，那太迟了，而且非常昂贵。微软的Steve Lipner在上周举行的RSA大会2011上发表了关于应用程序安全性的演讲，其中谈到在软件开发生命周期中的安全性。他向大家介绍了微软创建的安全性开发生命周期过程，其中包括以下阶段： 安全性培训 需求分析 设计 实现 验证 发布 反馈 另外，SDL框... [阅读全文]
企业级开发,企业级软件开发需要什么样的框架?
1）领域建模 分析领域特定的问题。比如赶集网这一分类信息网站，她的定位是解决都市人寻求房屋出租、二手房、二手车、二手物品交易、求职招聘等生活信息的需求的。在领域建模阶段要解决的就是这个软件的定位问题，做什么不做什么。这一阶段由高层领导，市场销售及系统分析师等完成。 2） 平台技术选择 技术选型，比如用什么平台/架构(.net,j2ee,php,python等等)开发，采... [阅读全文]
圣杯战争,零缺陷系统的圣杯
尽管零缺陷听上去很动听，但真有这种可能吗？还是说这是一个无法实现的目标？很多组织采用“零缺陷的方法”。这是否真的有意义？ Jim Bird认为，100%完美的成本是异常高昂的。一旦团队去除了90%的缺陷，到达了最佳水平，进一步去除缺陷所得的回报，相对于不成正比的成本而言，会明显降低。Jim引用了Ken Beck和Martin Fowler在《规划极限编程》中提到的观点： 但... [阅读全文]
测试用例,霜波说测试(一)– 优秀的测试用例
测试工程师有一样很重要的工作就编写测试用例。测试用例是对需求的另一种描述，它能引导大家进一步加深对系统的理解和对特性的全面关注，从而帮助产品和开发重新审核需求的合理性和一致性，所以应该是测试工程师最重要的一项产出。一般的测试用例分为输入，行为，和希望结果三个部分。这三个部分通常的测试用例都能满足，但是怎样的测试用例才能算上优秀的测试用例呢？基于以往之测试经验，我总结了优秀测试用例的几个特点。 1：... [阅读全文]
精益项目,怎样编写精益和敏捷项目的合同
Alan Shalloway在精益-敏捷邮件组中写道： 你有什么比较不错的，可以写进合同（或者工作计划）里，用来跟踪一个软件承包方的进度/效能的度量方法推荐吗？【...】然而【问题在于】，这一困惑在敏捷/精益/看板领域尤为突出。 Jeff Anderson给出了几条具体条款以作参考： 这些是我刚完成的合同中所包括的条款。我们有幸曾经真正地与客户一起完成过用户故事，因而对其复杂度有所了解。具体数据... [阅读全文]
明朝那些事儿3,研发的那些事3--接口之本
从前，有个程序， 只有一个模块，自己搞定所有事情，简单又快乐地生活着。后来，干的事多了，需要划分职责， 加了新模块，不过他们需要彼此沟通协调工作……好在是进程内的，如C#,Java之类的写几个Interface就搞定协作规范了。不过，再后来变成了两个程序 这下麻烦更大了，因为你说话时，对方可能睡着了zzZZ。甚至，你可能需要同老外交流，更甚至，对方可能来自遥远的半... [阅读全文]
软件项目需求管理,项目管理杂谈-需求无止境
项目又延期了，老板恨恨的批评了整个项目组，投入了那么多，产出在哪里？查原因，发现是由于项目的需求不断变更导致，这恐怕是很多项目经理、程序员都经历过的事。 我这里就谈谈项目延期的一个重要因素：需求问题 这张图大家再熟悉不过了，我再炒一下冷饭，列一下主要可能的情况： 客户提出的需求 项目组 客户期望的结果 是否满意 需求A 系统A 系统A 是 需求A 系统B 系统A 否 需求A 系统A 系统B 否 ... [阅读全文]
变形记,站立会议变形记
站立会议对于Scrum的意义，就像我们每天早上起来总是希望看看报纸，听听新闻，了解每日时事，关心国计民生。站立会议有助于Scrum Master以及整个团队了解项目进展情况，以便于控制项目进度，掌握团队成员的开发效率，促进成员之间的交流与沟通，并使所有成员对整个项目能有一个全面的认识。 站立会议的重要性不言而喻。如何遵循Scrum的原则开展好每天的站立会议呢？我在推行的Scrum实践中，发现站立... [阅读全文]
scrum,产品所有者也应该是Scrum教练吗?
Kulbhushan Sharma 询问了关于让一个人担任Scrum教练和产品所有者两个角色的问题： Scrum指引中指出，一个人可以同时是“团队成员”和“Scrum教练”，或者同时是“团队成员”和“产品所有者”，但是并没有明确地指出一个人可以同时担任“Scrum教练”和&ldq... [阅读全文]
热门话题：使用WCF实现SOA面向服务编程——SOA的概念
SOA的概念是Gartner 在1996年提出来的，并于2002年12月进一步提出SOA是“现代应用开发领域最重要的课题”。 一、SOA的定义 SOA分为广义的SOA和狭义的SOA，广义的SOA是指一种新的企业应用架构和企业IT基础架构，它可以使企业实现跨应用，跨部门，跨企业甚至跨 行业之间的离散系统实现互连。（注意：这里所指的服务并不单单是Web Service,它可以... [阅读全文]
软件开发管理之：编码负责人及标准代码库机制
软件工程中，涉及如下主要阶段：立项、需求、设计、编码开发、测试、发布、培训上线维护等，其中，编码开发如同整座软件大楼的砖瓦用料，将直接影响产品的功用、质量、性能。 编码开发过程中，往往是多人参与，团队作战，每个人的风格和技术水平不一，为规范作业，产生了编码规范，但规范往往比较缺少强制性，且不能从本质上使每个技术水平不一的各成员，其在项目中的编码水平保持在同一水准。 一般现用模式： 为使整个团队的... [阅读全文]
软件开发方法,软件开发方法需要理论
Semat计划于2009年12月由软件工程三位大师（合称“Troika”）Ivar Jacobson（UML、RUP、组件和组件架构、用例等技术之父），Bertrand Meyer（Eiffel和按约定设计之父）和Richard Soley（OMG主席）正式发起，倡导以坚实的理论、已经证明的原理和最佳实践为基础，重新发现软件工程的本质。Jacobson等撰写了三篇文章详细阐... [阅读全文]
管理咨询工具箱,敏捷咨询工具箱(三)──结对辅导
My mind to your mind. My thoughts to your thoughts... -- Mr. Spock 什么是结对辅导 在前面的两篇敏捷咨询工具箱中，我分享了如何做读书写代码活动和OO训练营。认真的做好这两项活动之后，团队的开发设计能力会提升一个台阶。对于有经验和有能力的团队，他们可以直接把这些技术和思想直接应用到项目中。但有一些团队还需要进一步... [阅读全文]
简单的web WebService安全
1. 有关生存期的补充正常情况下，每次调用 WebMethod，服务器都会创建一个新的 WebService 对象，即便客户端使用同一个代理对象多次调用 WebMethod。而我们一旦调用了有缓存标记的 WebMethod，只要未超出缓存期，WebService 对象都不会被重新创建。在缓存期内调用没有缓存标记的 WebMethod，也会继续使用该 WebService 对象。有太多因素让这个缓存... [阅读全文]
esb产品,ESB产品架构之愚见
1 主要概念 SOA ：英文全称是 Service-oriented architecture ，现在概念比较的不统一，主要由以下几种定义 W3C ：可以调用的一系列组件，其接口描述可以发布和发现。 CBDI ：一组策略，实践和框架，支持将应用程序功能作为一组服务在与能够调用，发布和发现的服务使用者相关的粒度发布; 这组服务是使用接口的单一标准形式从实现抽象出来的。 Gartn... [阅读全文]
安装守护程序失败,所有项目的失败真的都该归咎于程序吗?
今天，我读到了两篇有趣的文章：@unclebobmartin写的The Cost of Code 和 @DocOnDev 写的 Code as a Cause of Project Failure (读者可以分别在这里和这里阅读它们的中文版。)。 他们在用各种的论据来证明所有项目的失败都是由于程序的原因。他们主要的论点是：如果程序没有成本，轻巧易改变，项目就不可能失败。是的。但这些是极端情况，很显... [阅读全文]
成本核算程序,关于程序成本的讨论
昨天在#SCNA(北美2010软件技术大会)的一个专题小组讨论会上，@chadfowler 提出了这个问题：”有多少项目是因为程序的原因而失败的？“我想，他是想说造成项目失败的主要原因是业务问题，而非技术问题。 今天早上我把这个问题发布在了微博上。很快就有了回复，几乎所有人都认为导致项目失败的原因中业务问题是罪魁祸首。 完全没错，项目会因为成本，需求，进度计划，管理等问题... [阅读全文]
管理咨询工具箱,敏捷咨询工具箱(二)──OO训练营
犯错误是最好的学习方式。 ──莎伦·德雷珀 背景 我们为客户提供咨询，刚开始做了很多敏捷的实践，包括：持续集成、测试驱动、用户故事需求分析、迭代开发等等之后，发现如果再想深入下去，就会面临一些“硬骨头”：遗留系统和开发设计能力的问题。在一些客户那里，他们产品有10多年了，但是很少有人新加程序文件，写代码习惯于复制粘贴，都是... [阅读全文]
代码工具箱,敏捷咨询工具箱(一)──读书写代码活动
只要功夫深，铁杵磨成针。 ──宋·祝穆 在我们咨询过程中，遇到一些开发技术很薄弱的团队，大部分人只会通过复制和粘贴的方式写代码，然后花费大量的时间进行修改和调试。有些开发人员还只是刚刚从学校毕业，几乎没有什么开发经验。面对这样的团队，如何教他们使用敏捷开发方法？如何教他们测试驱动开发？如何教他们简单设计呢？ 如果连一门语言还没有完全吃透，还如何谈测试驱动开发和简... [阅读全文]
罪魁祸首,代码永远是罪魁祸首吗?
软件项目的失败可能归咎于各种各样的原因。一些项目因糟糕的需求而失败，另一些则由于钱和时间超支了，还有少数单纯是因为糟糕的管理所致。如果我们探究其根本原因，是否会发现所有项目失败的罪魁祸首是糟糕的代码呢？全都是这样吗？ Bob大叔坚信糟糕的代码所带来的成本之大足够让一个项目失败。他提到： 我知道许多项目都败在代码问题上。更有甚者，许多公司因为代码问题而失败。 Bob觉得原因其实很简单。若维护代码所需... [阅读全文]
敏捷软件测试,什么是敏捷软件测试
在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：“到底什么是敏捷软件测试？”，“敏捷软件开发还需要测试工程师吗？”。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程... [阅读全文]
明朝那些事儿,ERP那些事儿
做ERP已经快三年了，我从一个连ERP中文名是什么的小菜逐渐成长为一名可以独当一面的开发者，其间心酸苦辣难以言喻。ERP业界有一句话很值得推敲：企业不上ERP是等死，上ERP是找死。说的说企业如果不上ERP的话，那跟等死无异，但上了ERP如果不懂得管理，用户如果素质不够那也跟找死一样。如果把企业比喻成PC的硬件，那么ERP就是其中的OS了，可见ERP在现今企业运作是多么的重要。 ERP的实施运行可... [阅读全文]
软件开发生命周期,软件开发周期
1.开发人员开发出程序，深信里面没有缺陷。2.产品测试。发现了20个缺陷。3.开发人员修改了其中的10个，并向测试部门解释另外10个不是真正的缺陷。4.测试人员发现修改后的缺陷中有5个仍然有问题，并且又发现了15个新缺陷。5.第3步和第4步重复了3遍。6.由于市场的压力和由过度乐观的开发计划产生的仓促的产品声明，产品正式发布了。7.用户发现了137个新缺陷。8.最初的开发人员，兑换了他们的忠诚支票... [阅读全文]
破窗效应,软件开发中的破窗效应
应该有很多人已经知道破窗效应【注1】这个社会学 （犯罪学）的词语，破窗效应最先由社会学家James Q. Wilson和George L. Kelling在一篇名为《Broken Windows》的文章中提出【注2】：“一个房子如果窗户破了，没有人去修补，隔不久，其它的窗户也会莫名其妙地被人打破;一面墙，如果出现一些涂鸦没有被清洗掉，很快 的，墙上就布满了乱七八糟、不堪入目的东西;一个... [阅读全文]
生成器模式,生成器模式(又名建造者模式、Builder Pattern)
模式名称：生成器模式 1．问题描述 生活场景：你玩过种地、种花等类似的游戏吗？这是最近很流行的游戏哟！下面就是从种花游戏中剪切的四个花盆（盆景），很漂亮吧！你将不同的种子放入花盆，一段时间后你就可以看到各种美丽的鲜花了，不同种子所生产出来的鲜花有不同的花朵、叶子和枝茎。编码该如何实现呢？ 设计目标：将种子放入花盆，一段时间后就可以收获... [阅读全文]
变革的十年,软件工程的第四个十年,变革来临了吗?
Jean Bezivin, Nantes大学的名誉教授，在他最新的博客中，回忆了软件工程过去四十年的历史，因为他相信颠覆的时刻即将到来。Jean认为软件工程已经发生了三次巨变：第一次巨变在1968年10月的Garmisch NATO会议上已经讨论过了。复杂系统中所浮现出来的问题迫使我们认识到独立程序员时代已经结束了，将来的目标是“超过3万个指令的大型系统，由超过25个程序员在6个月（甚... [阅读全文]
信任也是一种约束,约束是一种隐蔽的优势
构建软件与管理大量的约束有着紧密的联系。这些约束可能是时间上的，也可能是资金、技术、决策、兼容性、管理、人员、过程或者以上所有方面的。Jim Bird探讨了Scrum、XP的约束，并讨论了这些约束如何帮助我们培养创造力并构建正确的软件。 关于约束，Jim提到了一个有趣的观察结果。但是，我很喜欢思考约束和限制的奇妙悖论：通过指引，通过强迫你用特定的方式思考和工作，通过限制你的选择，约束夺走你的控制... [阅读全文]
