20100601的主題，《簡單之美》之二，老倪

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] 謝謝老倪!

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-670360/，如需轉載，請註明出處，否則將追究法律責任。