其他

專案管理沙龍第五次聚會本次的話題從第30個項目百態模式《短鉛筆》開始。“短鉛筆”模式裡最讓人印象深刻的是這一句話“只有把用短的鉛筆交上去，才能更換一支長鉛筆”。很多人都遇過這樣的公司，因為要所謂的“控製成本”，結果卻把自己的員工當成了“賊”那樣提防，顯然這是一種錯誤的做法。有人在聚會上提出了另外的觀點，“成本控制無所謂好與壞，關鍵是從什麼角度去看”。不同的角度看問題，得到的結果是不一樣的，對於公司來說，當然是要千方百計盈利，所以“控製成本”本身並不是問題，但是在做法上一定要考慮“負面情緒”的影響

專案管理沙龍第六次聚會紀要--模式“蘋果酒屋”《項目百態》模式36名字叫“蘋果酒屋”。大意是說，蘋果酒屋是工人們下班之後的聚會場所，他們經常在吃完飯之後，一起爬到房頂上去乘涼，喝啤酒。於是女主管就制訂了蘋果酒屋規則，基本上就是“不許爬到房頂上”，“不許喧鬧”等諸如之類的規定。可想而知，這種“蘋果酒屋規則”不會有人遵守的。因為規則的制定者從來不會在蘋果酒屋住宿，也當然不會知道屋頂上是那裡唯一涼快的地方。這種“局外人”制定規則的情況在企業內部非常常見，最終的結局也都和“蘋果酒屋規則”差不多。會上列舉

分析模式讀書心得之責任模式Martin Fowler的《分析模式》買了許久，也看了很多遍，始終未能全部領會。這篇讀書心得也只是疏淺的一點看法而已。要說責任模式（Accountability）還需要先從組織架構的程式實現談起。凡是一個項目，或多或少都要涉及到部門組織架構的描述。目前我們的解決方案無非就是兩種：一種是需要遞迴的處理方式，另外是一種不需要遞迴的處理方式。所謂需要遞迴的處理方式，就是每一個部門採用如下的資料結構儲存：depart(dept_id,parent_id,

專案管理沙龍第七次聚會紀要本次沙龍的主題是由NSEC項目組介紹他們的敏捷實踐經驗。作為公司第一個實施敏捷的項目，他們的成績給整個公司帶來了震動，也是公司其他項目實施敏捷的參考和基礎。因為時間是所限，這次沙龍雖然只來得及只討論了NSEC的四個問題，不過逐個問題討論的過程中，我們涉及到了更多的方面。上次沙龍提出的“代碼秀”在NSEC實施了一周，效果不是很好，首先是頻率問題，上次沙龍談到的代碼秀周期是“周”或“月”為單位，NSEC的實踐證明以“天”為單位確實是太頻繁了；其次是項目組太忙了，沒時間總結，

用程式碼摺疊功能功能的時候，出現的情況就是如下：1public class2{3  void Hello()4  {5    Console.WriteLine("hello!world");6  }7}可是很多時候，我們如果貼了比較長的代碼之後，文章就會變得很長，最重要的是代碼會削弱文章所要表現或者突出的主題，對讀者的閱讀某種形式上構成了幹擾。所以，建議是否可以在程式碼摺疊功能上提供一個選項，“是否摺疊顯示”，就是說開始開啟頁面閱讀的時候，代碼就是處在摺疊狀態，如果要閱讀代碼，就需要自己去點一

 換一個角度再談一下WF 使用WF可以開發兩類流程業務狀態流程功能控制流程程 業務狀態類流程是傳統意義的工作流程平台所提供的流程,特點是用流程進行業務的狀態處理關於這方面的例子我已經寫過很多文章了,本文就不再談這方面的內容了 功能控制類流程在這裡先對功能控制類流程做個說明 舉個例子: 我們先對A表進行資料操作,再對B表進行資料操作.如果操作B表失敗,則復原對A表的操作. 當然,看到這裡你會說這不就是資料庫的交易處理嗎.是的沒錯,那我們將上面操作的複雜度提升一下  如上的流程就是,功能控制類流程他

專案管理沙龍第八次聚會紀要本次沙龍依然是NSEC的敏捷經驗總結。這次依然談到了客戶與需求的問題。因為客戶和開發組不在同一個地區，所以客戶完全沒有參與到項目的開發工作，所有的溝通都通過專案經理來進行。從開發人員的角度看，需求變化最大的問題是開發人員無法確定是否真的是對客戶有用的。客戶首先是自己有很多的想法，變來變去，PM也因為距離的關係，無法和客戶面對面溝通，所以也就只能拍腦袋和猜謎語。結果開發人員心裡沒底，做不出成就感，心情自然也就好不起來。引出的問題就是：開發人員到底怎麼辦？面對這種情況，經過

論人力資源的危機及其對策（4） 接上篇  記得N年前去參加戶外拓展訓練，其中有一個項目是“罐頭鞋”，就是三個汽油桶搭著2條木板，一隊人都站在上面，要求人不落地，集體前進2個木板長度的距離。很遺憾我們組失敗了，但是教官鼓勵我們說，你們還不是最差的，至少動了一半的路。然後說有一次他們給摩托羅拉的所有的人力資源主管們進行訓練，這些人站在木板上40分鐘的時間內一步都沒有挪動，所有的時間都費在嘴上了。大悅。這個是bigtall真實的經曆，也正巧反映了目前人力資源工作的現狀正是“說得多而做得少”。 這次找工

很多朋友問我該如何學習WF,在這裡提一點建議1.首先是基礎知識:這是必需要掌握的C#/VB文法、泛型、反射、委託、線程、oo思想2.你不可能不用資料庫，所以ADO.NET必需要掌握3.建模方面，至少要掌握流程圖、時序圖、共同作業圖表、狀態圖的繪製4.資料結構,設計模式至少要理解鏈表、二叉樹、職責鏈、命令模式4.為了實現元件服務，下面的組合要會一種WinServer,COM+,WebService,Remoting,WCF5.要掌握一種UI的展現方式ASP.NET或WinForm或6.有了以上的基

專案管理沙龍第十次聚會紀要會議一開始，就有人跟我們分享了一個名詞，“分析癱瘓”，意思是不斷地追求完美，結果始終在設計狀態，無法到下一步去。詳細可參考這個 http://hi.baidu.com/parad1se/blog/item/8724472a71b87e25d52af1a3.html 和

雖然接觸敏捷已經很久很久了，零零碎碎實施過，但是始終沒有機會將傳統的專案管理方法徹底拋棄，現在終於決定要徹底投入敏捷的懷抱了。為此我準備了整整一年的時間。我將會在這一系列的文章裡，請你和我一起分享這個改變的過程。傳統的scrum方式有三個角色：產品經理(Product Owner)，scrum教練(Scrum Master)和組員(Team

自訂Activity控制項可以繼承System.Workflow.ComponentModel.Activity寫一個功能類控制項，也可以繼承System.Workflow.Activities.SequenceActivity,將現有的Activity拖入進行組裝具體的功能擴充、整合與在NET下自定定組件沒什麼本質區別，但要注意一下自訂Activity的Execute方法圖解Execute方法  對VB.net 2.0 不熟的，注意一下事件的新寫法  Public Class 事件標記   

專案管理沙龍第十一次聚會紀要本來這次聚會要講一下專案管理的流程概貌，同時對第一個階段進行一次試探性的深入探討。可惜這次缺席人數太多，變成了“鏘鏘三人行”，原定想要談的內容，也就弱化了。其實每周一次的沙龍，並不需要太多的負擔，就當是每周一次的茶會吧，大家緊張了一整周，放鬆個90分鐘，也是應該的。不過“三人行必有我師焉”，只要有意願，肯定能夠談出新話題來。今天分享的知識是“Dreyfus模型”，全稱是“Dreyfus技能擷取模型(Dreyfus Model of Skills

文章目錄 總結

專案管理沙龍第十二次會議紀要本次會議的主題是為沒有敏捷共識的項目組定製一個敏捷的實施方法。這是一種普遍存在的情況，和其他的新事物一樣，總會有一些人對“敏捷”這兩個字比較敏感，究其原因，無外乎偏見、誤解和不瞭解（無知），部分人則是恐懼或自大。當然，不瞭解是絕大多數人的原因。但是，面對“沒有共識”的人們，到底是說服之後再實施敏捷呢，還是先實施敏捷再用實際效果展示給他們？這是一個問題。我們傾向於後者，即先實施讓人們看到效果。理由很簡單，因為人與人之間的知識和經曆的差異很大，要全部說服的時間成本太高，甚

專案管理沙龍第二次聚會紀要本次話題依然集中在敏捷方法和傳統專案管理的問題上，在兩次聚會之後，一些概念正在漸漸地清晰。有人提出，如果傳統專案管理方法將敏捷的一些做法接受過來，是不是也會變得敏捷起來呢？在討論中大家發現敏捷的一些做法原本就是早已存在的一些通用的做法，例如頭腦風暴、集體評估story的點數、週期性回顧總結、團隊工作等，這些做法傳統專案管理方法也在做，但是為什麼效果不如敏捷呢？關鍵還是在于敏捷和傳統方法的本質區別：後者認為人是需要監管的，需要一個專案經理去監督他們，不讓他們偷懶，並需要別

項目進度控制是專案經理的一項重要職責。俗語說的“時間就是金錢”在這裡體現得再明顯不過了。專案管理和自駕車回老家過年是相同的，實際上按照項目的定義，“自駕車回老家過年”也是一個不折不扣的項目，只是它更貼合大家的生活，更容易引起共鳴，我們就拿它來做例子說明。 從乘客的角度，如果坐車很久，但是沒有達到預期的目 的地的時候，就會產生疑問，一般都會去詢問司機“到哪裡了”，如果司機的回答沒有那麼令人滿意，這個疑問就會積累。積累到一定程度，就會開始懷疑是否迷

專案管理沙龍第四次聚會紀要--模式“快！趕上”和“死魚”今天聚會討論了兩個模式“快！趕上”和“死魚”，在 http://book.51cto.com/art/201101/244195.htm

1.前言看過太多的稱得上“三無”的軟體，就是無需求、無設計、無注釋。嚴格的說來，他們的需求和設計其實還是有的，只是沒有用文檔記錄下來而已，但是注釋確實真的沒有。這些軟體從大到小都有，但是他們都有一個共同的特點，就是“難維護”。前幾天和同事聊天，聽說一個XAML的實現要重寫了，用本地協議代替，然後再去考慮和XAML相容。雖然我沒有看過這個項目的代碼，但是我知道這個項目基本也是“三無”。當然這個情況也是三無的重大特徵之一，就是前腳走人之後，後腳是“看不懂、下不了手”，結果是還不如重寫來得簡單。從員工

WF流程設計器升級說明目錄WF流程設計器升級說明    1通用版    11.可開啟,設計,儲存所的xoml格式的工作流程檔案    12.提供了規則綁定    23.提供了綁定EventDrivenActivity與HandleExternalEventActivity