BlogJava-OOPAA-随笔分类-agile 敏捷

让非技术人员理解设计

mingj — Thu, 23 Dec 2010 15:55:00 GMT

摘要: 作为技术人员，我们经常需要跟客户、业务分析人员等非技术人员沟通软件设计方面的问题。如何比较直观地向这些非技术人员解释设计、软件质量对项目的影响，解释糟糕设计、不干净代码给项目带来的风险，解释我们必须开始关注软家设计问题？这里有两个概念（metaphor）可以帮助我们达到这一点。阅读全文

mingj 2010-12-23 23:55 发表评论

持续检查之sonar初体验

mingj — Wed, 22 Dec 2010 14:55:00 GMT

安装、启动Sonar：

Sonar的安装很容易，按照Sonar官方主页的安装指南解压缩即可。

Sonar默认使用derby作为数据库，你只需要在sonar.properties文件中去掉对derby数据库属性的注释，然后启动Apache derby数据库。

按照文档介绍，启动Sonar，默认的主页地址是http://localhost:9000，登录用户名和密码是sonar/sonar。

使用Sonar检查代码：

要使用Sonar检查代码，也很容易。

如果待检查项目是maven项目，则只需要安装sonar maven plugin即可；如果是非maven项目，则需要在项目根目录下创建pom.xml，内容按照文档配置。具体参见：http://docs.codehaus.org/display/SONAR/Analyzing+Java+Projects

现在只需要项目根目录下，运行mvn sonar:sonar就可以运行sonar maven plugin来检查项目中的代码了。

注意：

如果项目源文件使用的编码与系统的默认字符集不同，比如操作系统是GBK，而源文件编码为UTF-8。为了能够正常地检查代码，需要在pom.xml的properties元素下增加一项配置如:

<project.build.sourceEncoding>UTF-8project.build.sourceEncoding>

否则，sonar在生成checkstyle.xml的时候，不会将正确的编码传进去，导致checkstyle在做AST分析的过程中使用了错误的字符集，从而提示字符错误：“expecting 'xxx', but got ''”。即使是在调用mvn sonar:sonar的时候，增加参数如：

mvn -Dfile.encoding=UTF-8 -DsourceEncoding=UTF-8 sonar:sonar

也无法生效，虽然通过-e开关是可以看到系统的默认字符集已经改成了UTF-8。

好了，sonar已经安装完毕，而且也顺利地完成了代码的分析和检查。

下一步，我们就可以分析sonar输出的报告，判断代码的质量，制定改善的措施了。

mingj 2010-12-22 22:55 发表评论

浮潜与水肺潜水

mingj — Fri, 24 Sep 2010 13:05:00 GMT

摘要: 浮潜潜水员游弋于海水表层，看鱼戏浅滩，望影掠深海。水肺潜水员可以潜过海水表层的深度；他能潜到更深的地方，在一定的区域内研究那些影子以发现鱼类、沉船残骸以及珊瑚的细节。在相同的时间内，浮潜潜水员可以游历更宽阔的水域；而水肺潜水员则在潜游深度上占据优势。成功的项目团队在项目的整个过程中会把浮潜和水肺潜水这两种方式结合起来使用，在特定的时刻明智地选择合适的方法，从而有效地利用了时间。阅读全文

mingj 2010-09-24 21:05 发表评论

浓浓的特性汤

mingj — Mon, 13 Sep 2010 23:42:00 GMT

摘要: 在一开始的时候，一切都显得那么美好。市场部有一个来自于客户的请求——添加额外的下拉菜单。然后，在产品中添加一个输出接口的需求来了，产品经理想要加上一份新的分析报表，DBA要求在数据库里增加一个新字段以改变背景的颜色。所有这些需求以及其他更多的需求，都交由开发人员负责加进到产品里面。随着需求的不断添加，产品的特性集不断增长，但过了一段时间之后，每个人——市场部、客户和开发团队——对如何将所有这些碎片整合在一起、这些碎片如何帮助实现业务目标，失去了理解。曾经带着明确目标出发的项目变成了难以下咽的、由各种无关特性炖成的一锅汤。阅读全文

mingj 2010-09-14 07:42 发表评论

同事预审

mingj — Tue, 31 Aug 2010 13:19:00 GMT

摘要: 在如今大部分的组织里面，是否给申请技术职位的人提供工作机会——这个最终决定权属于管理部门。经理们雇人，经理们裁人：一切都天经地义。然而在某些组织里面，这些技术人员能否得到工作机会却是取决于——至少部分取决于——他们将来的同事。这种同事预审的最终结果只有一种：当经理们让技术职员拥有发言权的时候，每一个人——申请人、职员和经理——都会和盘托出自己的想法。阅读全文

mingj 2010-08-31 21:19 发表评论

一叶知秋

mingj — Tue, 03 Aug 2010 17:04:00 GMT

（一）
与客户吃饭。客户抱怨，“我司人员流失大，无法建设团队文化。”我说，“以你司推行的工具为例，其思路就是把团队定位于低级、傻瓜式的水平。那么，超出这个水平的人离去、不足这个水平的人加入，不正是延续并巩固了这种傻瓜式的团队文化么？”

（二）
工具或许无关好坏，但要警惕的是工具传递的创建者的价值观。推广工具遭遇困境，原因就在于推广者的价值观与接受者不合，双方价值观上面的认同没有到位。如果以外力强制推行，甚至上升为价值标准，孔夫子曰：始作俑者，其无后乎？

mingj 2010-08-04 01:04 发表评论

保姆型项目经理

mingj — Mon, 26 Jul 2010 15:38:00 GMT

摘要: 项目经理的很多技能都与传统的英式保姆有共同之处。阅读全文

mingj 2010-07-26 23:38 发表评论

欢乐的鼓掌会议

mingj — Tue, 20 Jul 2010 13:54:00 GMT

摘要: 高涨的士气永远象征着组织的健康。与之类似，低弱的士气则说明肯定有什么地方做错了。有一种管理理念就是奉这种关系如圭臬，试图从相反的方向来利用这种关系。逻辑是这样的：把士气鼓舞起来，其他美好的东西也就跟随而至。阅读全文

mingj 2010-07-20 21:54 发表评论

浅谈软件开发的权利和权力

mingj — Sat, 11 Jul 2009 09:37:00 GMT

摘要: 在日常生活中，有各种各样的法律规则和道德准则来约束、指导行为。比如在初次的商业合作中，双方都会选择制定一份详尽的合约来规约双方，包括双方拥有的具体权利、以及单方出错时对方享有的权利等。软件开发，在商业上面也必然会有详尽的合约，处理的是两个组织之间的利害关系。但是，软件开发同时作为紧密involve商业客户与开发团队的活动，正如Alistair Cockburn把它比喻称为game——由客户、管理层和开发人员共同play的game，其中也需要由参与play game的各方利害人来共同制定规则，让大家都能玩得开心、尽兴，甚至长久。这样，围绕着多赢长赢的出发点来play game，就同样需要这样一份“权利法案”，对开发过程中的三方利益利害人的权利做出基本的原则上的规定。在敏捷软件开发方法中，特别是极限编程中，就存在这样一份“权利法案”。阅读全文

mingj 2009-07-11 17:37 发表评论

AgileChina 2009: Pragmatic Agile [转]

mingj — Mon, 06 Jul 2009 11:57:00 GMT

摘要: 由在敏捷领域最具有影响力的技术社区InfoQ中文站、敏捷方法论的领导厂商 ThoughtWorks共同主办的敏捷中国技术大会（Agile China 2009），将于9月11日~12日（周五、周六）在北京举行。届时将有超过500人来自电信、金融、互联网、教育等行业在内的高级软件开发人员、项目管理人员等参加。本次大会将特别邀请敏捷宣言缔造者、敏捷编程（XP）方法学创始人Kent Beck，敏捷开发权威人士、敏捷宣言的创始人之一，Dave Thomas，敏捷宣言签署人之一Steve Freeman等国际敏捷领域专家，以及在团队中成功应用敏捷的阿尔卡特、赛门铁克、诺基亚-西门子、华为、腾讯等公司的项目负责人参与此次大会并分享他们的心得。阅读全文

mingj 2009-07-06 19:57 发表评论

敏捷，把纪律留下（下）

mingj — Thu, 18 Jun 2009 01:42:00 GMT

摘要: 在很多人看来，实施了敏捷，似乎就等于纵容程序员，允许他们不把纪律放在眼里。事实是这样子么？本文发表于《程序员》杂志2009年6期，因篇幅较长，故分为两段，本篇为下篇。阅读全文

mingj 2009-06-18 09:42 发表评论

敏捷，把纪律留下（上）

mingj — Thu, 18 Jun 2009 01:40:00 GMT

摘要: 在很多人看来，实施了敏捷，似乎就等于纵容程序员，允许他们不把纪律放在眼里。事实是这样子么？本文发表于《程序员》杂志2009年6期，因篇幅较长，故分为两段，本篇为上篇。阅读全文

mingj 2009-06-18 09:40 发表评论

迭代经理是什么角色？（下）【译】

mingj — Sun, 14 Jun 2009 07:45:00 GMT

摘要: 行业日新月异，敏捷、迭代式和迭代这些热门词已是“飞入寻常百姓家”，一个定义模糊的新角色——迭代经理，也浮出水面。这是新一代的项目经理么？抑或是美其名的团队带头人？又或者是管理上的一个新阶层？谁会被冠以这个“经理”头衔？本文将着重阐述迭代经理作为软件团队成员的工作内容和价值。我们将分析迭代经理的职责范围，同时讨论作为一个不可或缺的角色，迭代经理在面对组织和文化挑战的情况下，如何维持一个健康的工作环境。本文是全文的下部分。阅读全文

mingj 2009-06-14 15:45 发表评论

迭代经理是什么角色？（中）【译】

mingj — Sat, 13 Jun 2009 08:31:00 GMT

mingj 2009-06-13 16:31 发表评论

迭代经理是什么角色？（上）【译】

mingj — Sat, 13 Jun 2009 04:21:00 GMT

mingj 2009-06-13 12:21 发表评论

敏捷、生产力和商业价值

mingj — Fri, 22 May 2009 12:19:00 GMT

摘要: 我们曾举办了一次为期三天的敏捷培训，学员主要是一些知名软件公司的项目经理和资深开发人员。培训期间，我们带领学员进行了丰富的游戏，通过寓教于乐的方式让他们体验了敏捷方法学的大部分知名实践，并讲解了敏捷方法学推崇的价值和原则。从学员的回顾以及意见表上可以看出培训效果是显著的，但是在培训过程中学员也提到一些问题，主要是对敏捷方法学的实践和价值比较疑惑。在回答问题的同时，我们能感觉到随着敏捷方法学在国内被引入、被宣传，很多软件组织或人员对敏捷方法学都已经有了基本的了解，但是对敏捷方法学向软件行业承诺的价值还存在不同程度的顾虑。阅读全文

mingj 2009-05-22 20:19 发表评论

XP 与马克思主义趣谈－读《Extreme Programming Refactored: The Case Against XP》

mingj — Tue, 30 Dec 2008 16:52:00 GMT

    前一段时间读了Matt Stephens 与 Doug Rosenberg 合著的《Extreme Programming Refactored: The Case Against XP》（以下简称《Refactored》）。该书虽然是针对 Kent Beck 的《Extreme Programming Explained: Embracing Changes》（以下简称《Explained》）第一版进行阐发，然后 Kent Beck 在《Explained》第二版里面也修正了一些 XP 的理念和态度，但是《Refactored》书中提到的一些见解和看法现在读来还是挺有意思的。

    比如作者一开始就讲了个“皇帝的代码”的故事新编，把皇帝比喻成迷信开发方法的客户，然后 XP 者就是两个骗子，利用不具体的过程标准来欺骗现场客户以及审查的其他人，并赢得最后的release，却最终被小孩子揭露出来的故事。不可否认的是作者在其中做了过多的假设和有失偏颇的类比，最终使得故事显得过于荒诞和不切实际，但 XP 在那个急于推广自己的年代用一些过激的宣传词，从而引起这样那样的误解，也是正常的。这也是 Kent Beck 在《Explained》第二版里面修正的主要方面，使得 XP 更具可操作性，概念不显得那么的突兀而容易误解了。

    撇开这些不谈，觉得特别有意思的是作者在书中把 XP 和马克思主义来做对比，得出一些共同点，也颇让人若有所思。这里闲话不多讲，直接贴上书中几处 XP 和马克思主义进行对比的地方。

    1. XP 里面的代码共有与马克思主义提倡的集体所有制
    Just for fun, we did a little research on the subject of collectivism, outside of an XP context. It came from Marxist “power to the proletariat” sociopolitical theory (more on Marxism later). Here are a couple of interesting quotes that we found:
    Karl Marx -- “Since the supreme aim of collectivism is the abolition of that capitalistic regime which enables one man or one corporation arbitrarily to exploit the labour and the necessities of many men, it obviously does not—in theory at least—imply equal compensation for all individuals, nor the destruction of individual initiative, nor the establishment of a bureaucratic despotism.”
    然后引用 Robert C. Martin 的话就是：
    “The only constraint that XP puts on you is that any production code has be [sic] written by a pair. Your preferences and comfort do not supercede the delivery of quality to the project, or your parcitipation [sic] in the team.”

    2. XP 里面自组织团队与马克思主义提倡的人民专政
    Karl Mars -- Power to the Peeps

I was recently interviewing a programmer for a potential contract, and he happened to mention that he had worked on a project in which his team had attempted XP (but found it too difficult for various-reasons—in particular, that management wouldn’t buy in to the new way of working. Eventually they abandoned the “experiment” [which it quickly became known as], keeping unit tests but not much else).

I asked him what he most liked about XP, and he immediately perked up with, “It empowers the programmers! Puts us on an equal footing with the management. . . .”

    可以看到的是，这里面有些确实是 XP 没有解决好的问题，或者 XP 没有明示的东西。万幸的是，XP 不是一个固步自封的软件开发方法学，而是更注重它所强调的价值和原则，比如简单、沟通、勇气和反馈。所以，在实际开发过程中，不同的项目组在不同的项目环境下会裁剪出合适项目、合适组织的方法学。所以，前面两个问题其实在 XP 的框架内也都是可以解决的。

    我们来看第一个问题：代码共有导致个人失去成就感和幸福感。其实这个问题的更深层次是：
    1. 敏捷团队如何评价个人performance？
    2. 敏捷团队如何激励个人创造？

    其实这个问题也是我们在做培训的时候，学员们问得最多的问题。在传统的文档式开发过程中，开发人员的工作量被量化成代码行数或者 bug 修正数，虽然大家都知道这其实并不能反映真正的工作量，但毕竟可以作为他们衡量开发团队成员的 performance 的一个参考值。而 XP 一方面宣扬 pair programming 以及代码共有，另一方面又宣扬增进设计和重构，这样统计个人的代码行数或者修改的 bug 数对于绩效考核就没有任何帮助。那么，在敏捷里面是怎么解决这个问题的呢？

    我想，在检查个人performance在项目组内部通常都会有自己的办法，符合公司文化和价值的评审方法。以我们公司为例，通常是由每个人找4－5个项目同事来给他写 feedback，提供对这个人在项目里面表现的反馈。因为 XP 提倡勇气和反馈，所以，每个人也是会基于一个比较客观的态度来对同事进行评价。这样，从项目同事的反馈里面，就能得到比较全面的个人 performance 信息了。

    如何激励个人创造？对，因为 XP 提倡简单设计，通过重构来增进设计，所以在设计里面考虑更多的是设计是不是满足当前的业务需求，是不是容易让项目组其他成员所理解。但是，这并不意味着敏捷就不允许引入新技术，不允许进行大范围设计。这里不举我们公司的实践，在《透析敏捷编程》一书中提到了在项目组中使用“金卡”实践来激励个人创造，就是允许项目成员申请金卡来进行新技术研究或者大范围设计。因为 XP 提倡沟通和勇气，所以只要开发人员有具体理由，并且项目组同意个人在某方面花费时间精力，那就是应该尊重和允许的。

    所以，从上面来看，XP 并不会导致个人失去成就感，重点在于项目组是否足够 XP，足够敏捷来让每个人都达到自己的幸福感和成就感。如果没有，建议通过团队 retropective 来找出有效的改进方法。

    我们再来看第二个问题：在项目组内，程序人员地位不比项目管理人员差。其实这个问题的更深层次问题是：
    1. 程序人员应该听从管理人员的指挥，怎么能提出异议呢？
    2. 如果程序人员有自己的想法，那管理还能进行下去么？

    那么，我想大部分拥有这个疑虑的人应该是传统的项目经理。但是自从在 javaeye 里面看了一篇把开发团队比喻成正规军的比喻之后，我发现有些开发人员也倾向于接收管理人员的命令，而不是更积极主动地提供自己的建议，去和管理人员进行更有效的沟通。其实，我们在做培训的时候，和一些项目经理也谈过这方面的问题。开发人员不善于与他们沟通，导致他们对开发团队的真实状态不清楚，他们觉得非常不放心，于是反过来进一步要求开发团队提交更多的文档来反映他们的状态。这样，开发团队文档任务增重了，怨声载道，项目经理就更得不到项目团队的真实状态了。于是，恶性循环就形成了。

    在开发过程中，随时都有可能会发生影响项目交付的问题，比如原来估算的工作量有偏差、客户对某一处需求提出了修改等等。很多事情项目经理是不可能事无巨细都会察觉的。这些问题在传统软件方法学里面都是作为风险来管理的，于是项目经理在预防各种各样的风险中忙得焦头烂额，“兵马未动，粮草先行”，不到最后一刻不敢让开发人员进行开发。因为一旦进行开发，而开发人员不积极主动反馈项目状态的话，项目经理对于项目就是完全失控了。这是项目经理无论如何不敢面对的。可是，“防民之口，甚于防川”，项目开发过程的风险，是能完全堵死的么？如果开发人员可以有机会，也无风险地发表自己的看法，项目管理就可以是更轻松了的。而且，一个人的智慧总是有限的，当客户逼着你做决定的时候，你不希望项目团队的人能站出来，助你一臂之力么？把全部责任都一肩扛，只会对项目不利，而谈不上有益。从另一个方面讲，每个人都是希望有一个上升的职业生涯，希望能不断提升自己。软件组织也是希望能不断涌现表现优秀的员工，从而有利于组织的成长。那为什么要打压开发人员积极参与管理的兴趣和付出，最终影响组织的成长呢？

    在培训中，大多数项目经理也能认识到项目团队沟通的重要性，但对怎么建设这样的团队仍然显得方法不多。XP 作为充分照顾了人性的方法学，也是提出很多原则允许或者鼓励开发人员积极沟通，表达自己的想法。所以，运用 XP，建设好简单、勇气、沟通和反馈的良好氛围的团队，不仅对于每个团队成员，对于项目经理，对于其他管理人员都是有百益而无一害的。为什么不尝试一下呢？

    马克思主义说过“集体所有制”、“人民专政”，毛泽东思想也说过“实事求是”，邓小平理论更是说“不管白猫黑猫，抓到耗子就是好猫”。在《Refactored》提到的一些误解，其实都不能作为反对实施敏捷的理由。我想，如果果真是阻力重重，或者不知道如何开头，或许可以考虑请求于一些专门提供敏捷咨询的第三方组织了。

mingj 2008-12-31 00:52 发表评论

由某手机厂商现状漫谈敏捷

mingj — Thu, 18 Dec 2008 05:58:00 GMT

摘要: 目前有很多软件组织陷入在软件开发的焦泥坑中，面临着种种不同而又复杂的情况。分析其根源，重量的、不能及时反馈改进的软件方法是原因之一。而在现实中，项目管理层往往通过增加人力等手段，却又陷入 Brooks' Law 的迷雾之中。企图一劳永逸，通过大规模过程改进来提升交付能力，更是被 Fred Brooks 斥为“there is no silver bullet”。这种情况下，敏捷方法的出现自有它的优点，不仅就软件开发的本质复杂性，而且也就软件开发的附加复杂性进行了有益的探索。这些探索被证明是有效而且长期的，只是落实到具体人、具体实践上面，又是被歪嘴和尚念了真经。阅读全文

mingj 2008-12-18 13:58 发表评论