2010-6-1 12:29:32  [nj-sa-sh] 还有两分钟开始了
  2010-6-1 12:29:33  [mazd-Melody-PM-上海] ready
  2010-6-1 12:29:38  [tina－信息管理－南京] 倒计时
  2010-6-1 12:29:47  [谷雨霖pharos-cto-北京 群主页www.pmbar.net] 嗯
  2010-6-1 12:30:19  [nj-sa-sh] 今天还是介绍下书里提到的内容
  2010-6-1 12:31:34  [海茶-SSE&PMP-北京] 还好，今天没迟到。
  2010-6-1 12:31:34  [nj-sa-sh] 还有一些观点
  2010-6-1 12:31:34  [nj-sa-sh] 上次讨论需求部分比较多
  2010-6-1 12:31:49  [ddv731731-SSE-上海] :)
  2010-6-1 12:31:57  [nj-sa-sh] 开始吧
  2010-6-1 12:32:01  [windland1979-pm-bj] :)
  2010-6-1 12:32:12  [nj-sa-sh] 大家有问题可以及时提
  2010-6-1 12:32:20  [nj-sa-sh] :)
  2010-6-1 12:32:48  [谷雨霖pharos-cto-北京 群主页www.pmbar.net] 好
  2010-6-1 12:32:48  [nj-sa-sh] 简单之美，这本书主要是讲方法和思想的
  2010-6-1 12:33:07  [nj-sa-sh] 内容包括了软件开发的方方面面
  2010-6-1 12:33:08  [Bobby-PM-XM] 鼓掌
  2010-6-1 12:33:25  [nj-sa-sh] 谢谢:$
  2010-6-1 12:33:56  [成成-HRM-上海] 开始学习了
  2010-6-1 12:34:11  [wgl-pm-bj] 正好赶上！
  2010-6-1 12:34:11  [bluestar-coding-bj] 鼓掌
  2010-6-1 12:34:12  [nj-sa-sh] 之所以涉及得比较全面，是因为我认为软件开发是个系统的工程
  2010-6-1 12:34:15  [wgl-pm-bj] 欢迎！
  2010-6-1 12:34:45  [nj-sa-sh] 一个点上或一些点上的一些解决方案，放到上下文中就有不同的效果
  2010-6-1 12:35:21  [nj-sa-sh] 虽然内容比较繁杂，但是，有一些原则性的东西是很明确的
  2010-6-1 12:35:42  [nj-sa-sh] 比如说，简单之美想要表达的简单原则
  2010-6-1 12:36:07  [nj-sa-sh] 还有软件开发的创造性，想象的精神
  2010-6-1 12:36:22  [nj-sa-sh] 以及时刻关注以人为本的文化
  2010-6-1 12:37:09  [nj-sa-sh] 这三点是核心的想法，所以，我在书的第一章，就表达了这几个观点，然后用一些例子来证明
  2010-6-1 12:37:32  [nj-sa-sh] 证明这些想法是可行的，主要还是从自己的软件开发实践出发
  2010-6-1 12:38:12  [nj-sa-sh] 我认为抱着这些原则，是开始软件开发的好的基础
  2010-6-1 12:38:58  [nj-sa-sh] 其次，我认为的一个重要方面，是软件开发方法论，相比于那些思想原则，这个就比较具体了
  2010-6-1 12:39:32  [nj-sa-sh] 在书里面，我以CMM和敏捷方法为例，介绍了自己的一些想法
  2010-6-1 12:40:12  [nj-sa-sh] 比如说，CMM，我曾经有过实施CMM和参与评估的经历
  2010-6-1 12:41:01  [nj-sa-sh] 很多朋友认为CMM带来了很多事务性的工作，比如文档和比较重的过程
  2010-6-1 12:41:23  [nj-sa-sh] 我当时和SEI的评估师沟通过
  2010-6-1 12:41:43  [nj-sa-sh] 在他的眼里，CMM其实是非常灵活的，灵活来自于裁剪
  2010-6-1 12:42:20  [nj-sa-sh] 我们之所以构建一个大而全的过程库
  2010-6-1 12:42:55  [nj-sa-sh] 是为了在全面理解软件开发成熟模型的基础上，有能力去做灵活的裁剪
  2010-6-1 12:43:18  [nj-sa-sh] 就像练马步
  2010-6-1 12:43:47  [nj-sa-sh] 是基础，临敌之计是帮不上大用场的
  2010-6-1 12:44:06  [nj-sa-sh] 但是没有对基础的理解，就很难知道什么才是灵活
  2010-6-1 12:44:27  [nj-sa-sh] 所以，我认为CMM是帮助我们走在一条成熟之路上
  2010-6-1 12:44:58  [nj-sa-sh] 它裁剪的灵活性，我在书里有一个同行评审的例子
  2010-6-1 12:45:28  [nj-sa-sh] 当然，最核心的东西是不能也不该放弃的
  2010-6-1 12:46:05  [nj-sa-sh] 例如，我们要想规划下我们的工作，我们的工作成果要记录下来，然后不断持续改进
  2010-6-1 12:46:52  [nj-sa-sh] 这比我们两手空空，每次都随意开会讨论，没有任何结果的情况要好得多
  2010-6-1 12:47:27  [nj-sa-sh] 但是，我觉得CMM对人的关注度还不够
  2010-6-1 12:47:40  [nj-sa-sh] 这在敏捷方法中得到了补充
  2010-6-1 12:48:21  [nj-sa-sh] 敏捷方法对人的关注很高，但是对人的要求也很高
  2010-6-1 12:48:36  [nj-sa-sh] 这是非常客观的一个情况
  2010-6-1 12:48:48  [nj-sa-sh] 我曾经参与过一些敏捷开发
  2010-6-1 12:49:55  [nj-sa-sh] 比方说，每天开晨会，划分故事，燃尽图
  2010-6-1 12:50:46  [nj-sa-sh] 结果很多都成了应付，或者有默契地夸大故事的复杂度，划分过于细致
  2010-6-1 12:51:20  [nj-sa-sh] 而且，很多管理者，以敏捷实施的情况，作为考核标准
  2010-6-1 12:51:34  [nj-sa-sh] 例如每天解决多少问题，bug数多少
  2010-6-1 12:51:59  [谷雨霖pharos-cto-北京 群主页www.pmbar.net] 欢迎新朋友
  2010-6-1 12:52:08  [nj-sa-sh] 我感觉这是不对的，这违背了敏捷的原则，而把敏捷作为另一个管理手段
  2010-6-1 12:52:48  [nj-sa-sh] 其实，敏捷基于以人为本的文化，本质上是相信人们可以主动
  2010-6-1 12:53:12  [nj-sa-sh] 敏捷的方法，是解决主动工作的开发人员，在工作方式上的需要
  2010-6-1 12:53:34  [nj-sa-sh] 他们需要沟通，所以有晨会
  2010-6-1 12:53:55  [nj-sa-sh] 他们需要了解开发的状况，所以需要燃尽图
  2010-6-1 12:54:36  [nj-sa-sh] 如果开发人员不需要，或没有感觉到需要，敏捷方法的实施就很难成功了
  2010-6-1 12:54:46  【系统提示】Viki将昵称更改为Viki-PM-SZ
  2010-6-1 12:55:12  [nj-sa-sh] 敏捷方法提供了很多有趣的“剧本”，也就是一些好的实践方法集
  2010-6-1 12:55:30  [谷雨霖pharos-cto-北京 群主页www.pmbar.net] 谢谢
  2010-6-1 12:56:05  [nj-sa-sh] 这对于软件开发人员是好的。但是，我们常常看到一些相反的效果
  2010-6-1 12:56:37  [Aiken-PM-湖南] pmp
  2010-6-1 12:57:11  [海茶-SSE&PMP-北京] 非常认同老倪对敏捷的这段描述，忍不住出来赞一下。
  2010-6-1 12:57:12  [nj-sa-sh] 比如说结对编程，我自己非常喜欢结对编程，但是在实践中，意见不同，争论，不一定都带来积极的效果。这和人们的认识有关
  2010-6-1 12:57:29  [nj-sa-sh] 谢谢:)
  2010-6-1 12:58:37  [nj-sa-sh] 所以我们要把问题放到一个大环境中来看，例如，企业文化，责权利问题，决策问题等等，不能割裂那些问题来做
  2010-6-1 12:59:21  [(L) 明君] 好
  2010-6-1 12:59:25  [nj-sa-sh] 在书里，我设想了一种“更好”的方法论
  2010-6-1 12:59:51  [nj-sa-sh] 也不是说更好，就是更适合变化的
  2010-6-1 13:00:03  [nj-sa-sh] 所谓中庸之道
  2010-6-1 13:00:30  [nj-sa-sh] 中庸，就是在能力和目标之间去寻找最佳的平衡点
  2010-6-1 13:00:59  [nj-sa-sh] 是动态的。每个企业都有不同的文化，要不断摸索才行
  2010-6-1 13:01:35  [nj-sa-sh] 其中我讲到，要有一种兼容并蓄的价值观
  2010-6-1 13:02:42  [nj-sa-sh] 很多问题和价值观有关。我还提到，最好企业要有个调整员工心理的部门，呵呵。智力活动密集型的企业
  2010-6-1 13:03:17  [nj-sa-sh] 最根本的就是人们内在的主动性。否则，几乎没有办法来衡量
  2010-6-1 13:03:41  [孙东-PM总监-北京] 您对每日构建，持续集成如何看
  2010-6-1 13:03:48  [wgl-pm-bj] 赞同老倪的观点，调整员工心理的确重要，但是在企业没有这种部门的情况下，怎么做很关键啊。。。也很头疼啊
  2010-6-1 13:04:00  [pw-PM-CD] 这个层次有点高了
  2010-6-1 13:04:17  [nj-sa-sh] 另外，还谈到执行问题，从约束到习惯，文化氛围的转变，是最好的执行方式
  2010-6-1 13:04:37  [nj-sa-sh] 等等
  2010-6-1 13:04:59  [nj-sa-sh] 后面一章是需求问题，这个上次谈得比较多
  2010-6-1 13:05:22  [nj-sa-sh] 其中有一个观点，可能会带来不少争议
  2010-6-1 13:06:01  [nj-sa-sh] 软件开发成本，更多来自于设计和实现的细节，而不是需求的扩大
  2010-6-1 13:06:32  [nj-sa-sh] 这个观点也不完全是我说的
  2010-6-1 13:07:05  [nj-sa-sh] 我在Steve McConnell的观点中找到了相同的想法
  2010-6-1 13:07:10  [pw-PM-CD] 蛋生鸡？鸡生蛋？
  2010-6-1 13:07:17  [nj-sa-sh] Steve McConnell提到的一个观点非常有趣。
“（工作量成倍增加）其中的关键在于，真正的不幸存在于细节中，即基于开发者对于表面上不起眼的细节的不同理解，可能对实现的时间产生非常大的改变。”

  2010-6-1 13:07:48  [nj-sa-sh] 我之所以这么想，也有实践的支持
  2010-6-1 13:08:01  [nj-sa-sh] 我曾经经历过一个项目
  2010-6-1 13:08:24  [nj-sa-sh] 在设计初期，使用了jdbc和hibernate混用，导致了非常严重的性能问题
  2010-6-1 13:08:29  [pw-PM-CD] 设计与实现的细节会发现新的需求，新的需要务必增加设计和实现的细节
  2010-6-1 13:09:06  [nj-sa-sh] 后面，想要对架构做一些修改，就需要20个人月以上的工作量
  2010-6-1 13:09:46  [孙东-PM总监-北京] 同意
  2010-6-1 13:10:05  [nj-sa-sh] 这个想法可能需要大家去工作中体会了
  2010-6-1 13:10:48  [nj-sa-sh] 后面的一章是软件架构的思考
  2010-6-1 13:11:48  [nj-sa-sh] 包括再后面的一章，软件实现的思考，稍微多一些涉及技术方面
  2010-6-1 13:12:21  [nj-sa-sh] 在这两章，我还是比较强调简单化的原则
  2010-6-1 13:12:43  [nj-sa-sh] 比方说，可移植性问题
  2010-6-1 13:13:00  [nj-sa-sh] 我们很多架构，都把业务逻辑和平台或框架结合得非常紧密
  2010-6-1 13:13:14  [nj-sa-sh] 这是错误的
  2010-6-1 13:14:20  [nj-sa-sh] 业务逻辑牵涉到的，应该就是业务模型和算法，和平台框架的结合部位，要严格分离
  2010-6-1 13:15:04  [nj-sa-sh] 这可以使业务逻辑有重用的价值，有可移植的机会，最终将降低我们的开发成本
  2010-6-1 13:15:40  [nj-sa-sh] 在这两章中，我还提到了软件开发中的负责文化
  2010-6-1 13:16:12  [nj-sa-sh] 在实践中，我们经常碰到没有责任人的问题
  2010-6-1 13:16:59  [nj-sa-sh] 在会议中，大家都可以发表意见，而且很多有话语权的开发人员可以左右解决方案
  2010-6-1 13:17:29  [nj-sa-sh] 但是，当问题出现的时候，没有人承担责任
  2010-6-1 13:17:55  [nj-sa-sh] 所以，我特别觉得软件开发应该像个外科手术团队一样
  2010-6-1 13:18:06  [nj-sa-sh] 要有主刀医生
  2010-6-1 13:19:02  [nj-sa-sh] 他可以选择符合他设计思想的方案，手术成功与否，他是主要的责任人
  2010-6-1 13:20:05  [nj-sa-sh] 软件架构应该由一个架构师，或者以一个架构师为主导的团队来完成
  2010-6-1 13:21:11  [谷雨霖pharos-cto-北京 群主页www.pmbar.net] 嗯
  2010-6-1 13:21:11  [nj-sa-sh] 敏捷方法中说，团队设计，那也是一个自发组合的团队
  2010-6-1 13:21:11  [nj-sa-sh] 由于大家有相似的思想，所以团队工作也不算太离谱
  2010-6-1 13:21:51  [nj-sa-sh] 责任从来都是和利益相关的
  2010-6-1 13:22:19  [nj-sa-sh] 所以在书里也做了讨论。
  2010-6-1 13:22:37  [nj-sa-sh] 和责任密切相关的，就是软件开发中的决策了
  2010-6-1 13:22:37  [max-pm-sh] 没有人承担责任是一方面，推卸责任也是比较恶劣的
  2010-6-1 13:22:39  [不胜人生一场醉-正式求职-海口 ] 但事实上多数项目中只有一个能称得上架构师的高手
  2010-6-1 13:22:51  [不胜人生一场醉-正式求职-海口 ] 其他人都还是得围绕他来转的
  2010-6-1 13:23:00  [nj-sa-sh] 对，我也提到了这个问题
  2010-6-1 13:23:11  [nj-sa-sh] 这需要企业经营者的工作了
  2010-6-1 13:23:46  [nj-sa-sh] 很多时候，企业中的做法都是由上而下的
  2010-6-1 13:23:54  [nj-sa-sh] 这种做法风险很大
  2010-6-1 13:24:03  [wgl-pm-bj] 其实还有另一种情况，很多项目有时候连一个称得上架构师的都没有，呵呵呵
  2010-6-1 13:24:14  [nj-sa-sh] 呵呵，对
  2010-6-1 13:24:35  [nj-sa-sh] 所以企业经营者还要有识人的能力
  2010-6-1 13:24:48  [孙东-PM总监-北京] 没架构就加班
  2010-6-1 13:24:50  [nj-sa-sh] 有一个方法可以检测
  2010-6-1 13:24:53  [成成-HRM-上海] 还有公司，有架构师也起不到作用
  2010-6-1 13:24:57  [wgl-pm-bj] 在架构设计时，大部分是做技术和项目经理等半吊子在那里设计架构，
  2010-6-1 13:25:03  [nj-sa-sh] 在书里面也提到了，呵呵
  2010-6-1 13:25:10  [不胜人生一场醉-正式求职-海口 ] 而且架构的层次也很多
  2010-6-1 13:25:19  [wgl-pm-bj] 结果造成你上面说的很多问题。。。
  2010-6-1 13:25:25  [成成-HRM-上海] 是呀
  2010-6-1 13:26:10  [nj-sa-sh] Alistair CockBurn在敏捷软件开发一书中，还提到一个故事。
Dave A. Thomas是Object Technology International的创始人，这是一家拥有很多成功项目记录的公司。一天，他向我总结了他的成功公式：“有些人能交付软件，有些人不能。

我雇用那些交付过软件的人”。

  2010-6-1 13:26:10  [不胜人生一场醉-正式求职-海口 ] 很难说架构师应该发挥什么样的功能
硬件网络拓扑、BS架构、设计模式
  2010-6-1 13:26:30  [wgl-pm-bj] 特别是性能、扩展性、移植性等方面出现很多问题，造成大量的返工。。。
  2010-6-1 13:26:45  [nj-sa-sh] 呵呵，其实检验的方式很简单，这就是我说要有下而上去做些事
  2010-6-1 13:27:09  [wgl-pm-bj] 没太明白，老倪，解释一下？
  2010-6-1 13:27:09  [谷雨霖pharos-cto-北京 群主页www.pmbar.net] 对于中小企业，没有架构也有准架构，没有准架构还有高级工程师。一步步来的，不可能一蹴而就。
  2010-6-1 13:27:10  [谷雨霖pharos-cto-北京 群主页www.pmbar.net] 所谓经验是实践的积累
  2010-6-1 13:27:24  [nj-sa-sh] 有试点，就像特区，在不影响公司商业利益的前提下，从最小的单位做起
  2010-6-1 13:27:49  [nj-sa-sh] 逐渐推广
  2010-6-1 13:29:41  [孙东-PM总监-北京] 问题永远存在，关键是目标和交付
  2010-6-1 13:29:41  [nj-sa-sh] 识别出人才是很难的
  2010-6-1 13:29:41  [nj-sa-sh] 短期是这样，长期就需要不断积累和进步了
  2010-6-1 13:29:41  [nj-sa-sh] 在书里的最后一章，谈到了知识积累的问题
  2010-6-1 13:31:42  [谷雨霖pharos-cto-北京 群主页www.pmbar.net] 赞同
  2010-6-1 13:31:42  [谷雨霖pharos-cto-北京 群主页www.pmbar.net] 不能简单认为没有什么所以做不了什么
  2010-6-1 13:31:42  [nj-sa-sh] 对
  2010-6-1 13:31:42  [nj-sa-sh] 后面还谈到软件决策的问题
  2010-6-1 13:33:43  [谷雨霖pharos-cto-北京 群主页www.pmbar.net] 大家有什么问题？抓住老倪的机会啊。哈哈。
  2010-6-1 13:33:43  [成成-HRM-上海] 时间太短，还没学习充分呀
  2010-6-1 13:33:43  [nj-sa-sh] 解决方案永远比问题多，决策就是选择，成千上万的选择
  2010-6-1 13:33:44  [nj-sa-sh] 这都依赖于人，人才
  2010-6-1 13:33:44  [nj-sa-sh] 任何过程都解决不了
  2010-6-1 13:33:44  [nj-sa-sh] 一个小决策，就会影响巨大。比方说
  2010-6-1 13:33:44  [susan-pa-襄樊] 业务模型和算法，和平台框架的结合部位，要严格分离。 我不是开发人员，不知道怎么衡量？

  2010-6-1 13:33:49  [nj-sa-sh] 决策用oracle的plsql来实现业务逻辑，可是当碰到一个大客户，但是没有购买oracle的计划，这会造成商务上的被动
  2010-6-1 13:33:50  [nj-sa-sh] 比方说，java企业应用中，一个http request，在进入业务计算前，就不再出现了
  2010-6-1 13:34:10  [nj-sa-sh] sessionbean，不会参与到业务计算中
  2010-6-1 13:34:55  [nj-sa-sh] 等等。反正框架和平台特有的东西，都尽量远离业务计算
  2010-6-1 13:35:01  [nj-sa-sh] 业务计算就是模型和算法
  2010-6-1 13:35:21  [nj-sa-sh] 这对单元测试都是一件好事
  2010-6-1 13:35:45  [nj-sa-sh] 很多时候，耦合性高了，测试一个业务逻辑，是非常困难的
  2010-6-1 13:36:05  [susan-pa-襄樊] 是的
  2010-6-1 13:36:12  [不胜人生一场醉-正式求职-海口 ] 这个有点绝对，有时候为了效率起见会做平衡的
  2010-6-1 13:36:22  [字宽-失业-上海] 架构，如何评价？或者从哪些方面来评价
  2010-6-1 13:36:42  [nj-sa-sh] 怎么会影响效率呢
  2010-6-1 13:36:54  [nj-sa-sh] 在内存中计算是效率最好的啊
  2010-6-1 13:37:05  [不胜人生一场醉-正式求职-海口 ] 错了，SQL返回的是最快的
  2010-6-1 13:37:25  [pw-PM-CD] 我想指的是通讯效率
  2010-6-1 13:37:29  [nj-sa-sh] sql会访问数据库啊，网络开销很大的
  2010-6-1 13:37:39  [pw-PM-CD] 调用层次太多
  2010-6-1 13:37:40  [不胜人生一场醉-正式求职-海口 ] 100万条记录在内存分页和排序，你认为如何？
  2010-6-1 13:38:31  [不胜人生一场醉-正式求职-海口 ] 良好的框架不一定导致必然有效率的结果
  2010-6-1 13:38:36  [nj-sa-sh] 这不绝对啊，原则是那样的。要看业务场景
  2010-6-1 13:38:59  [nj-sa-sh] 为什么要在内存中分页100万条数据呢？
  2010-6-1 13:40:04  [nj-sa-sh] 呵呵，是的，凡事都不绝对。可是不好的框架导致低效率的情况肯定会高很多啊
  2010-6-1 13:42:01  [nj-sa-sh] 前段时间一直在性能调优，在书里软件测试一章，有一节谈到了我的那次经历
  2010-6-1 13:42:39  [nj-sa-sh] 已经13:40了
  2010-6-1 13:42:50  [nj-sa-sh] 要不今天就到这里:)
  2010-6-1 13:43:06  [susan-pa-襄樊] 谢谢老倪
  2010-6-1 13:43:23  [hitbird开启尘封的记忆-无聊中-北京] :D非常感谢～
  2010-6-1 13:43:33  [不胜人生一场醉-正式求职-海口 ] 鼓掌一下啊
  2010-6-1 13:43:36  [nj-sa-sh] 不客气，谢谢大家:)
  2010-6-1 13:43:56  [mazd-Melody-PM-上海] 感谢
  2010-6-1 13:45:48  [海茶-SSE&PMP-北京] 老倪前面讲的中庸之道我觉得可能更适合比较高的组织层面，具体到项目层面我觉得还是得用成败之道。这两道追求的目标本质上讲

应该是一致的：都是为了达成共识，实现目标。但是中庸之道更多的是通过和稀泥的方式调和利益纷争，达到组织层面的共识；而成败之道讲的就是事事论成败，时时求结果。项

目层面如果用中庸之道，容易在和稀泥的过程中迷失了目标，放弃了结果，最终导致项目失去控制。
  2010-6-1 13:46:01  [max-pm-sh] 鼓掌。
  2010-6-1 13:46:07  [海茶-SSE&PMP-北京] 谢谢老倪今天的演讲！
  2010-6-1 13:46:46  [谷雨霖pharos-cto-北京 群主页www.pmbar.net] 谢谢老倪的分享！
  2010-6-1 13:46:49  [谷雨霖pharos-cto-北京 群主页www.pmbar.net] 非常精彩
  2010-6-1 13:46:52  [susan-pa-襄樊] 鼓掌
  2010-6-1 13:47:02  [Bobby-PM-XM] 鼓掌
  2010-6-1 13:47:03  [lwantstudy-PMO-DaLian] 谢谢老倪!