developerly的专栏

笔者在一家日本企业里面从事软件开发工作。作为一家典型的日本企业，软件开发的流程显然是按着日本的软件工程方式进行的。同样作为一家日企，在很多方面和欧美企业有着截然不同的开发角度。这里想讨论的，就是对Review和对Test的一些看法日本企业对review是十分看重的。他们认为review是解决bug最好的办法，在开发中甚至会采用过度review的办法。比较典型的是我们开发课长的想法:既然现在在工业生

昨天，优快云举办了一个程序员沙龙，我一般是少有参加这样的活动的，不过昨天却是例外，因为昨天请来的，正是敏捷开发的创始人之一，Martin Fowler。不知道他身份的话，远远望去，也不过是一个很普通的老外，络腮胡子，秃顶的脑门（这使我想到了C++创始人那同样秃顶的脑门，是不是每个聪明的人都回绝顶啊）。现在就不客观的回顾一下昨天的演讲，为什么叫不客观呢，因为我不能忠实的记录大师的每一句话，我在听的

不知道最近是不是运气不好，总是在格式上与leader或是课长等人发生争执。我是一个实用主义者，在讲究效率的开发过程中，对那些为了对应“以后”，“可能”的情况，而产生的纷繁复杂的表格是很不以为然地。稍微分析一下我当前的情况先。这周，主要做的是代码分析。当然，我们的组长就创造一个一个很复杂的文档模版，首先要写上他做的测试项，1，2，3；然后对每条测试项要写出流程；然后再写上数据库相关；然后再以表格的形

今天看的的第三章我印象最为深刻的是以下两点：“迅速，但不匆忙”“掌握平衡”其实东方的智慧真的是很神气。我记得曾仕强在《中国式管理》中就提到，中国人的智慧就像太极一样，讲究平衡而不是走极端。现在看来，敏捷的思维正是在向这个方向迈进。掌握平衡，区分软件开发活动中静态与动态的活动，鼓励创新同时又能引导团队往目标前进，不正是管理的智慧？

真没有想到，精简的开发方式居然最开始来自日本。可是在我现在的公司却丝毫没有感受到任何的精简。我试着统计过，在一个星期的软件开发周期中，做详细设计要花2天时间，然后就是详细设计Review1天时间，1时间编程，还要花1天时间作coding review，至于填写各种Review表格和写测试项嘛，只能加班完成了。也就是说，真正产生客户价值的地方只花了1/5的时间。也许你会说其他的工作都是为了更好的完成

今天把第一章的最后一部分看完了。有一些文字印象深刻：敏捷项目管理是新东西吗？既是也不是。复杂性理论告诉我们，通过重组现有“积木”，直到出现不同的生物体这种方式，可以改变生物剂。“积木”，这正是我所需要的词汇。不管是敏捷还是传统的项目管理，从某种意义上来说，都需要借鉴开发过程的“积木”。这个积木可能是从标准流程发展下来的活动/任务模块，或者证明对过去项目团队行之有效的做法，并将这些做法与核心的价值观

这是本书的第二章，首要的就是讲述了顾客在开发过程中的重要性。关于这点，我有一些自己的理解。关于什么是客户，书中的回答：“用创造的产品产生商业价值的个人或者群体”。看起来很简单的回答，并没有完全解决我们可能遇到的问题。比如下面这种情况：A公司计划开发一种ERP产品，他已经通过B咨询公司做了市场调查并得出了目标用户（对ERP有诉求的企业）的需求。A公司没有能力完全独立的开发这个产品，它又把产品开发的一

仿佛是为了应证书中所描述的混沌世界。我是在混乱之中打开了这本《敏捷项目管理》。周围的人，聊天的，唱歌的，玩游戏的。反正我最近周末的情况总是非常地糟糕，没有一个安静的读书环境。有时候真的很怀恋大学的时光，午后阳光下，一杯清茶，一本好书——生活就是这么简单。不过，人嘛，终究要适应变化。敏捷不仅仅是软件开发的智慧，也是人生的智慧。希望我能适应变化，取得更大的进步。闲话少说，谈谈这本书。这不是一本讲述怎样

关于敏捷和CMM，以及怎样在CMMI的框架下有效的引入敏捷的开发，是我所一直关注的话题，最近在网上闲逛，看到ThoughtWorks总经理郭晓在软博会上的演讲，觉得讲得不错，现转载如下（转载于网易科技）：实际上我们软件产业要发展就要创新，在当前这种形势下，具体讲我们怎么样创新和融合，我觉得胡主任的报告做了一个非常好的报告和研究。我觉得是值得大家借鉴的。下面大家都知道，我们对于软件产业的发展过程中，

其实企业内部的知识共享是一个很复杂的问题。每个人都有自己的经验和Key Knowledge，每次开发也能积累到很多有用的开发经验或者教训。可是怎样才能进行有效的知识共享呢？一个完善的知识共享系统应该具有以下几种特性易于使用的界面，好的知识共享系统应该容易被使用。这个易于使用包括以下两个方面：共享自己的知识和分享别人的知识。很难想象一个程序员在工作之余会使用很复杂的登陆系统来记录自己的心得。同样的，

 下面是我对优快云上面一个学生写的《学生使用极限编程进行团队开发的方案》的评论：原文地址：http://blog.youkuaiyun.com/AimarC/archive/2005/06/01/385279.aspx我的评论如下：与其讨论XP的开发方法，我更愿意讨论敏捷开发。敏捷最终要的是什么，就是拥抱变化，所以在没有具体项目的情况下，定出的原则或是方案都有点之上谈兵的感觉。一定要时时

大凡在日企里面做过leader的项目管理人员都比较喜欢review吧。今天早上收到课长的email，提到：“质量是做出来的，而不是检测出来的；高质量不等于高成本，高质量是预防出来的*”……“测试是验证，而不是保证质量。高质量不一定要多加人，延长交货期。提高质量，要有良好的设计，严格的执行（过程管理/配置管理，含review）”。结合平时的经验，所谓过程管理和配置管理都是比较务虚的东

真不明白居然会有人以加班为乐趣，估计在他的心里面生活的乐趣也不过而而了。的确我现在正在加班，也确实想写篇blog来发泄一下。不过，既然我发表在管理观察这样一个栏目里面，自然要一如既往地理性分析。一，管人与管物。刚看到《程序员》杂志上有篇文章说道这方面的内容，其见解与我不约而同，禁不住拍案叫绝。的确，不管是ISO规范也好，还是CMMI规范也好，都少有提到员工管理这方面的内容。如果我记得不错的话，CM

最近班加的着实厉害。头儿恨恨的说，那在企业里面就是这样，到项目快完成的时候就得加班，那什么个人生活啊，都放到一边去！你们要受不了，就走人。呵呵，要是现在走不用给公司违约金的话，我还真会有这个考虑。读了一些书，诸如《人月神话》，可是还是改变不了我这个小人物昨天，或是今天必须加班的命运。但是却妨碍不了我的思考。记得联想公司大裁员的时候，有人在网上写过一篇文章《公司不是我的家》，的确，公司不

真的很感谢优快云再一次带给我们这样机会，让我们能够聆听到世界一流软件工程专家的演讲。也许看过我博客的朋友以前也看过我听Martin Fowler演讲时候写的报道，呵呵。可惜今天去的时候没有作好充分的准备（居然迟到了，faint），就没有办法再写一篇“不客观”报道了，只能写一些我的肤浅的感受了。 本来是做好要听一场宣扬非常“笨重”软件工程学方法准备的，没想到一开篇，Ivar博士就不断地提到一个词汇