OOPAA

          Focusing on OO, Patterns, Architecture, and Agile
          posts - 29, comments - 75, trackbacks - 0, articles - 0
            BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

          敏捷,把紀律留下(上)

          Posted on 2009-06-18 09:40 mingj 閱讀(4145) 評論(0)  編輯  收藏 所屬分類: agile 敏捷 、PM 項目管理

          (本文發(fā)表于《程序員》2009年第6期,轉載請注明。


          在軟件行業(yè),大部分經(jīng)理們都希望自己率領的團隊能像軍隊一樣具有鐵的紀律性。在一次敏捷培訓中,我們與眾多來自國內軟件公司的項目經(jīng)理們討論了敏捷,以及他們現(xiàn)在各自的開發(fā)方法和問題。閑談中,一位學員冒出一句,開發(fā)團隊應該像軍隊,不僅要整體陣法嚴密,而且每個兵都要紀律分明。這次培訓主要是介紹敏捷的技術實踐,比如測試驅動開發(fā)、持續(xù)集成、用戶故事等,該學員認為這些敏捷實踐不僅可以提高員工的技戰(zhàn)術,還可以塑造團隊成員的紀律性。如果這些敏捷實踐在日常開發(fā)中都能落在實處,勢必將提高團隊成員的戰(zhàn)斗素養(yǎng)戰(zhàn)術素養(yǎng)。一言以蔽之,相較于其他軟件開發(fā)模式,敏捷方法對團隊成員的紀律性提出了更高的要求,鼓勵團隊成員成長為項目經(jīng)理心中的合格軍人。

          其實,拋開敏捷方法,哪一種軟件開發(fā)方法又何嘗不強調團隊成員的紀律性?計劃驅動的傳統(tǒng)型開發(fā)方法給軟件過程制定了嚴格的計劃書和檢驗標準,希望能提高團隊的紀律性。它們的出發(fā)點是對的,但因為缺少了具體的技術實踐導致計劃書并不能匹配團隊的真實狀態(tài);檢驗標準大多是著眼于與最終交付軟件無關的中間文檔,這些都使得成員在工作中對項目開發(fā)的約束力感受不深。比如,很多項目里面的規(guī)范說明書、WBS表和甘特圖都畫得非常詳細,但大多數(shù)時候這些東西與項目真實情況的落差太大,很難指導督促成員的日常開發(fā)工作。而且,這些文檔與需要交付的軟件產品的關聯(lián)性不強,也很難能讓成員和其他人通過這些文檔建立對軟件交付的信心。長期看到團隊的表現(xiàn)與計劃的不相符,項目經(jīng)理們往往會感嘆團隊的紀律性不行。那么,為什么說敏捷方法能相對一定有效地提升團隊成員的紀律性呢?我們先來看看紀律的定義。

          紀律

          一般來說,紀律有三種基本涵義:1.紀律是指懲罰;2.紀律是指通過施加外部約束達到糾正行為目的的手段;3.紀律是指對自身行為起作用的內在約束力。這三層意思概括了紀律的基本內涵,同時也反映出良好紀律的形成過程是一個由外在的強迫紀律逐步過渡到內在自律的過程。從紀律的含義來看,達到自律是最終的目標,也是施加外部約束的目的所在。通過獎懲來達到一定的紀律性,比如程序員開發(fā)過程中的bug率等等,這是生活中最常見的一種形式。這種方法因為檢查的結果與具體生產過程差得太遠,而且評判標準還是比較粗放,所以應該是最低級的方式。施加外部約束,比如檢查列表,指導產品的具體生產,可以評判成員的各個環(huán)節(jié)是否符合標準,應該算中級方式。只有自律,真正讓成員把紀律的觀念貫穿在生產的每個環(huán)節(jié),主動改進,從而改善生產。而這,也是紀律性的高級方式。

          對比這個標準,我們可以看到:計劃驅動型的軟件方法學強調更多的是獎懲,也涉及到一些外部約束(代碼復審等),這也是為什么它們在培養(yǎng)團隊成員紀律性上難度比較大。而敏捷方法,通過強調承諾,強調每個成員都是理性人的事實,借助于成員的自律性來達到嚴明的紀律性。國內有一家業(yè)內非常有名的技術網(wǎng)站InfoQ,四月份在北京舉行的QCon Beijing就是由InfoQ主辦。除了有限的幾位全職員工,大部分的中文編輯都是社區(qū)的活躍分子,他們走到一起,通過之間的承諾和信任維持著日常工作,也給全國技術愛好者傳播國內外的業(yè)界最新新聞和技術。撇開具體項目團隊而言,這就是敏捷團隊最好的寫照。但是,我們也應該看到,InfoQ類型的團隊是可遇不可求的?,F(xiàn)實中,大部分的開發(fā)團隊還是良莠不齊,項目經(jīng)理們很難去完全授權給手下的員工。為什么敏捷方法又能有效地提升成員紀律性呢?答案在于敏捷方法不僅僅強調承諾,也包含了豐富的技術實踐:不僅給個人帶來更短更頻繁的反饋,也給團隊和組織帶來了多層次較全面的反饋。而反饋的頻繁程度,則是外部約束發(fā)揮作用的重要基礎,也即提升紀律性的重要手段。

          戴明環(huán)(PDCA

          我們來看看被認為是組織或團隊改進或解決質量問題的基本準則的戴明環(huán)。戴明環(huán)(PDCA)是由美國質量管理博士戴明在20世紀50年代提出,PDCA是英語單詞Plan(計劃)、Do(執(zhí)行)、Check(檢查)和Action(行動)的第一個字母,PDCA循環(huán)按照計劃-執(zhí)行-檢查-行動的順序進行,并且循環(huán)不止地進行下去,是一個立體多層級的螺旋式的演化過程。PDCA循環(huán)最開始是用在質量管理領域,但實際上它是有效進行任何一項工作的合乎邏輯的工作程序,是放之四海而皆準的指導性原則。下面我們就用它來說明外部約束對紀律養(yǎng)成是如何影響。

          PDCA循環(huán)里面的Action是一個循環(huán)的關鍵,對Check的結果進行處理,成功的經(jīng)驗加以肯定并適當推廣、標準化;失敗的教訓加以總結,未解決的問題放到下一個PDCA循環(huán)里,但它必須以上一環(huán)節(jié)的Check結果為基礎。如果Check不到位,不能具體到實際工作,Action的正確性和出發(fā)依據(jù)就很值得商榷。軟件開發(fā)是一個以不確定性為主要特征,強調知識的活動。為了采取的Action具有較高的正確幾率,更需要強調開發(fā)過程的Check比較頻繁、具體,不斷給團隊提出直接的反饋,這樣才能減少不斷累積的不確定性最后帶來成不可控制的后果。如此來看,短而頻繁的反饋對外來約束真正施加到個人的效果是非常重要的。

          PDCA循環(huán)還有一個特點是多層級性:各層級質量管理都有一個PDCA循環(huán),形成一個大環(huán)套小環(huán),一環(huán)扣一環(huán),互相制約,互為補充的有機整體。軟件開發(fā)通常會把個人、團隊和組織都牽扯進來:個人完成功能的開發(fā),團隊完成軟件的開發(fā),組織負責完成客戶需求的完成。傳統(tǒng)的軟件開發(fā)方法更多的是強調團隊、組織層級的計劃、圖表等文檔,關注于團隊與組織層級的反饋。對于真正創(chuàng)造產品質量的日常開發(fā)環(huán)節(jié),則缺少必要的檢查和反饋。與之相反,支撐敏捷方法的敏捷實踐,就從個人-團隊-組織的幾個層面都提供了相應的反饋:低層次的反饋,為上一層次的反饋提供了依據(jù),同時也作為上一層次反饋的落實和具體。


          --未完待續(xù)--

           

          主站蜘蛛池模板: 永平县| 沁水县| 锦屏县| 息烽县| 庆城县| 静海县| 稷山县| 房山区| 郓城县| 济南市| 定襄县| 诸城市| 孙吴县| 新丰县| 东至县| 怀仁县| 伊金霍洛旗| 永川市| 新巴尔虎左旗| 马关县| 奎屯市| 竹北市| 兴文县| 中阳县| 钟祥市| 息烽县| 化德县| 重庆市| 玉龙| 林甸县| 刚察县| 略阳县| 河津市| 成安县| 民县| 宁波市| 洛南县| 桂林市| 扎囊县| 饶阳县| 扬中市|