|
“領導者是教練,不是裁判”—— W Edward Deming并不是在ScrumMaster課程上說的這句話,但毋庸置疑——這句話能引起每個名副其實的ScrumMaster的共鳴。 Deming是上世紀對現(xiàn)代管理學形成有重大影響的思想領袖之一。他在設計、制造、銷售和質(zhì)量方面的學說對日本經(jīng)濟發(fā)展產(chǎn)生了深遠影響,他也因此舉世聞 名。日本比美國更先采用了Deming(一個美國人)的學說,并因此取得了巨大的生產(chǎn)力和質(zhì)量的提高。他的學說幫助日本公司制造出優(yōu)秀的產(chǎn)品,占領國際市 場,因而飽受贊譽。為了肯定Deming所作的貢獻,日本科學技術聯(lián)盟(JUSE)以他命名了日本的國家質(zhì)量獎。Deming獎是世界上最早的、在制造業(yè) 最有影響力的獎項之一。不久之后,Deming學說也開始在美國被采用。晚年,他致力于幫助福特汽車(Ford Motors)和施樂(Xerox)等公司的高層們改進他們的管理風格。 Deming學說要怎么和敏捷軟 件開發(fā)相結(jié)合呢?畢竟,他的學說關注的是制造業(yè)的效率——而傳統(tǒng)瀑布軟件開發(fā)方法論的一些缺點,就是因為嘗試采用傳統(tǒng)工程流程來構(gòu)建軟件而導致的直接惡 果。作為敏捷方法的實踐者——我們當然想要認清軟件項目的不同特質(zhì),從而避免用傳統(tǒng)方法中的弊端。然而這些學說中的管理理念其實超越了特定的工程學科。其 中豐富的智慧如若善加利用,將能幫助提高敏捷實踐的有效性。 Deming學說最著名的部分是他于1986年發(fā)表的《擺脫危 機》(“Out of the Crisis”)一書中的管理建議集。也就是著名的“Deming學說十四要點”(“Deming’s 14 Points”)。這十四點和敏捷實踐的相關性不容小覷。隨著敏捷過程日漸成熟,作為實踐者的我們要忠于敏捷宣言的精神,而不要被敏捷方法諸多變種所定義 的形形色色的任務牽著鼻子走,就顯得至關重要。這么做的一個可靠途徑就是在做項目時用Deming學說十四要點來檢視我們的判斷。我們可以用這些要點作為 隱性的指南來驅(qū)動項目。接下來的部分,本文將逐個探討要點的相關性,并闡述它們在敏捷項目中是怎樣充當指南的。 要點一:樹立改進產(chǎn)品和服務的長久使命,以使企業(yè)保持競爭力,確保企業(yè)的生存和發(fā)展并能夠向人們提供工作機會。 很多組織的軟件開發(fā)人員認為他們自己和商業(yè)戰(zhàn)略方向沒有什么關系。只做表面功夫的敏捷實踐常常會助長這種認識。在實踐短期迭代并且短周期發(fā)布的過程中,團隊常常犯無視當前迭代以外的——或者充其量,當前項目以外的任何東西這一類錯誤。 Deming學說不僅倡導經(jīng)營要關注它的目的,對軟件團隊而言,它也強調(diào)一個經(jīng)常被忽視的最佳實踐——理解你們項目的真正目的,并忠于它。 開發(fā)軟件產(chǎn)品是為了實現(xiàn)一些特定的商業(yè)目標。這些目標來源于公司的戰(zhàn)略方向。公司戰(zhàn)略又以市場戰(zhàn)略為依托,通過產(chǎn)品組合計劃來貫徹執(zhí)行。在實現(xiàn)眾多項目中的單個小故事點過程中,時刻不忘整體戰(zhàn)略視圖(圖1)顯得尤為重要。 為了有效地開發(fā)一個產(chǎn)品,項目團隊需要理解公司的整體戰(zhàn)略,以及必要的、與項目相關的市場和產(chǎn)品戰(zhàn)略。一個具體的迭代可能有3或4個用戶故事點要開發(fā),而在開發(fā)這些故事點時,關鍵要謹記整體總是大于局部之和。如果我們僅僅關注單個故事點,而沒有考慮這些故事點對產(chǎn)品其它部分以及系列產(chǎn)品的影響,我們很可能沒辦法使這個故事點物盡其用。 舉個很簡單的例子——迭代中有個故事點要開發(fā)一個從外部捕獲數(shù)據(jù)源的web service。故事點可能對所捕獲數(shù)據(jù)的用途只字未提。在這種情況下,除非開發(fā)人員知道這些數(shù)據(jù)在下游產(chǎn)品中的用途,否則他不可能很好地為這些數(shù)據(jù)設計 出持久性策略。如果這些數(shù)據(jù)需要進一步的轉(zhuǎn)換,它就需要經(jīng)過某種處理——而如果它只是以報告為目的的,可能就要用另一種完全不同的方法了。 這個層面的認知只能通過花時間來學習產(chǎn)品戰(zhàn)略方向、預期用途、目標用戶和使用期限。 圖一:故事點的戰(zhàn)略性視圖 Deming的這個要點還強調(diào)了有效溝通的必要性。通常商業(yè)利害關系人并不花時間來講解產(chǎn)品的用途,而工程師們也懶得弄清楚這些。因此團隊常常無休止地糾纏于紛繁的目標之間無法自拔,最終只能以低質(zhì)量的、不滿足公司真正需求的產(chǎn)品來收場。 在這點上有兩個最佳實踐能幫上忙: * 預先制定一份較粗的、涵蓋整個項目的計劃——這可能看起來和敏捷理論有些背道而馳,但實際上并不。敏捷原則只建議不要預先做細分到任務層面的計劃——但它 并不是勸阻任何層面的計劃。能展示里程碑并列出產(chǎn)品所有主要特性的、較粗的計劃有助于為單個故事點提供必要的上下文環(huán)境。 * 將產(chǎn)品愿景寫成文檔,并經(jīng)常和所有的利害關系人溝通確認。愿景文檔不需要很詳細——但它應該包括足夠的信息,能夠清楚地解釋產(chǎn)品背后的戰(zhàn)略、預期用途和發(fā) 起者的期望。隨后團隊要特別重視在項目過程中定期地回顧一下愿景文檔,并做一些必要的航向修正以保持與愿景同步。 要點二:接受新的理念。在一個新的經(jīng)濟時代,西方管理者必須意識到自己的責任,直面挑戰(zhàn),領導變革。 Deming學說在這里主要關注的是領導層。他希望敦促管理者們接受改革并將其融入到組織生活中去。Deming這里所指的改革源于全面質(zhì)量管理的實踐。它要求管理者作為表率,帶領工人們一起,讓組織在不斷變化的經(jīng)濟環(huán)境中朝著它的競爭目標勇往直前。 組織改革跟實施敏捷再親不過了。敏捷理念的醉翁之意本就不止于開發(fā)團隊的變革。成功的敏捷實施要求行政大佬以及各方利害關系人都進場,做組織架構(gòu)的調(diào)整——只有高層支持,這一切才能得以實現(xiàn)。許多敏捷團隊的失敗正是由于缺乏高層支持,最終不得不重回瀑布式開發(fā)。 敏捷為技術項目引入了一個新思路——它要求采取全新的產(chǎn)品市場策略,改革產(chǎn)品發(fā)布方式和預算機制,與此同時,也要對客戶服務和銷售的運營方式做 相應調(diào)整。敏捷開發(fā)能使各方精英匯聚一堂,齊放異彩——然而如果產(chǎn)品計劃不能隨團隊增量開發(fā)而與時俱進,或者營銷信息沒有根據(jù)增量發(fā)布做相應調(diào)整,最終結(jié) 果還是不會盡如人意。只有能夠打破部門界限的高效跨職能團隊,以及足夠的高層支持,才能實現(xiàn)統(tǒng)一步調(diào),成就大業(yè)。 不論你喜歡不喜歡,這一過程都需要時間和耐心。這可能是在組織中實施變革的最大難題。但無論如何,它都是達到成功的關鍵要素,非做不可。 有一個加速此過程的途徑,就是在組織里設一個敏捷傳道士的角色。這個角色要讓一個嫻熟的敏捷主義者擔當,這樣既可以和管理高層保持有效良好的溝通,又可以對形形色色的利害關系人進行淳淳善誘。 要點三:不要將質(zhì)量依賴于檢驗。要從一開始就將質(zhì)量滲透或融入產(chǎn)品之中,從而消除檢驗的必要性。 對大多數(shù)軟件項目而言,質(zhì)量是馬后炮。這像是給開發(fā)過程狗尾續(xù)貂,而且大家都覺得這僅僅是測試組的職責所在。 敏捷則用一個徹底不同的方法實現(xiàn)高質(zhì)量——這一方法其實就是Deming的要點本身。高質(zhì)量是不能通過測試人員檢驗開發(fā)人員完成的工作來實現(xiàn) 的。高質(zhì)量只能通過開發(fā)人員、需求分析員、架構(gòu)師和測試人員同心協(xié)力,把質(zhì)量檢測作為每個人工作的一部分來完成,才能得以實現(xiàn)。測試人員需要關注的是測試 在商業(yè)需求方面產(chǎn)品的表現(xiàn)如何。他們不應該測試某個代碼單元的實現(xiàn)正確與否。每個開發(fā)人員要致力于產(chǎn)出高質(zhì)量的代碼;這些代碼則要達到設計的預期。 敏捷方法有一些很棒的實踐就是針對打造高質(zhì)量產(chǎn)品的。測試驅(qū)動開發(fā)的實踐——加上持續(xù)集成,如果實施得當,就能大大減少低質(zhì)量產(chǎn)品流入測試階段的機會。實施這些過程有時看起來像空中樓閣,并不是所有的開發(fā)團隊都有足夠的設施以及資源來完全實現(xiàn)它們。 但將質(zhì)量意識根植到每項要做的任務中是一個對任何團隊都有益的目標。 另外一個直接影響高質(zhì)量的關鍵因素是所有利害關系人的緊密參與。敏捷的一個核心原則就是“業(yè)務人員和開發(fā)人員必須通力協(xié)作,且貫穿項目過程的每一天”。(http:///principles.html) 那些不能獲得業(yè)務專家、用戶群、市場營銷、銷售以及其它商業(yè)相關人員積極參與度的項目,通常就會在前期失去了構(gòu)建高質(zhì)量的先機。隨后這些項目只好依賴事后檢驗,還以低質(zhì)量產(chǎn)品而告終。 如在前面部分的三點討論中我們所看到的,Deming學說和敏捷項目原則顯示了驚人的一致。無論是敏捷新人,還是有經(jīng)驗的敏捷實踐者們都可以把這些要點當做一套簡要指南來幫助他們實現(xiàn)敏捷。在接下來的期刊中,我們將繼續(xù)討論剩下的十一個要點以及他們和敏捷世界的關系。 |
|
|
來自: bigyellowdoc > 《軟件項目管理》