• <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>
    • 軟件測試技術
    • 軟件測試博客
    • 軟件測試視頻
    • 開源軟件測試技術
    • 軟件測試論壇
    • 軟件測試沙龍
    • 軟件測試資料下載
    • 軟件測試雜志
    • 軟件測試人才招聘
      暫時沒有公告

    字號: | 推薦給好友 上一篇 | 下一篇

    如何成為 XP 客戶

    發布: 2007-5-26 21:59 | 作者: 未知 | 來源: 系統分析之窗 | 查看: 17次 | 進入軟件測試論壇討論

    領測軟件測試網

    如何成為 XP 客戶

    --了解驅動軟件項目意味著什么

    IBM DeveloperWorks
    Roy W. Miller(rmiller@rolemodelsoft.com)
    軟件開發人員,RoleModel Software, Inc.
    2003 年 4 月

    在上次的專欄文章中,您了解了讓 XP 發揮作用所需要的心態。團隊的每個人都必須改變他們的思維方式。本文探討了為什么客戶(業務決策制定者)似乎要在這一轉變中經歷最困難的時期。除非他們改變思維方式并參與到軟件項目中,否則最終結果永遠不會令人滿意。
    Roy 歡迎您提出要討論的主題或 XP 領域內的其它任何事情。請在關于本文的論壇中與作者和其他讀者分享您的想法(您也可以單擊本文頂部或底部的“討論”來訪問論壇)。

    XP 需要業務人員的思維方式有一個深刻的轉變。在過去 30 年的時間里,軟件開發方法學已經使企業中非技術人員習慣于按某些方式思考和行動。遺憾的是,傳統方法學是錯的,因為它們并不總是產生這些人想要的結果:在項目結束時滿足其需要的軟件、有較長有用期的軟件和及時交付的軟件。

    討論的是一個很苛刻的要求。令人遺憾的事實是傳統軟件開發始終不能及時交付。其中的一個主要原因人們可能根本不會想到:客戶沒有做他們的工作。在我進行說明之前,您需要理解 XP 項目的“客戶”有哪些特征。

    不可能實現的夢想?

    XP 描述了一個美好的情形?蛻簦ɑ蜻_成一致的一組人)告訴程序員編寫什么樣的軟件?蛻魳俗R某種特性并給出為什么這很有必要的理由。理想情況下,客戶會量化該特性 — 它的最低要求是什么?盡管量化一種特性并非總是可能的,但卻始終是值得一試的目標。如果它是不可能的,不要讓這一點阻止您生產優秀的軟件,但不要假定它始終都是不可能的。試試看。

    軟件應該由業務需求來驅動,但通常的情況卻是技術人員領導項目。他們構建他們想構建的東西,這通常是因為客戶在項目一開始時就擅離職守,或者是程序員在某些時刻放棄與業務人員交談。為什么會這樣?軟件開發的歷史已經使所有參與的人都習慣以某些方式思考和行動。太多的情況下,結果是失望、窘迫和挫折。

    深陷于泰勒制

    Frederick W. Taylor在 19 世紀 80 年代是一家機械工廠的工長,在此后超過三十年的時間里他一直在研究工廠生產。他注意到一個最重要的特征:低效。他開始通過尋找做任何工作的“唯一最佳方法”,以及告訴管理人員如何為他們操作的每一環節找到最佳方法的系統,來消除低效。到 20 世紀 50 年代為止,泰勒制(Taylorism)是主要的管理哲學。企業的軟件開發在那個十年里首次登場,經營企業的人作出了一個看似不錯的假定。他們假定適用于其它生產類型的相同管理原則 — 考慮工作的相同方式 — 也適用于軟件。

    考慮一下汽車裝配線。零件和原料從這一頭進去,裝配好的汽車從另一頭出來。您最不想看到的事是:裝配線上的每個人聚在一起決定改為造自行車。裝配線上沒有機會進行創造。您真正想要的是可預見性 — 您希望裝配線每次運行都完全相同。在這一領域,問題與解決方案始終是相同的,而您可以有效地優化該過程。當然,一旦您把事情優化并使其平穩運行,那么“變化”就變成了敵人。即使環境在底層是動態的,人們也會費盡心力地使它看上去可預見。

    “效率”的這種模型根本不適合軟件。對于軟件,問題始終是不同的。它可能類似于您以前看到過的,但決不是相同的。這就意味著解決方案不可能相同。不可能只遵守手冊就能獲得正確的答案。如果問題不同而且解決方案不同,那么您不必考慮優化。它根本就不存在。變化是不斷的。

    在某種程度上,您可以說軟件開發團隊(對于內部或外部用戶)受困于裝配線式的思維方式。泰勒制給企業文化打下了深深的烙印。擔當軟件項目客戶的人通常是管理用戶群的人,或者本身就是用戶。如果他們管理用戶,那他們就是經理。如果他們本身就是用戶,那他們就處于由經理們控制的環境中。無論哪種情況,裝配線式思維方式都是標準。

    參與軟件開發的業務人員已經開始相信他們的角色主要是前端的:他們在開發周期的早期為程序員指定一組詳盡且不變的需求,然后停下來等待結果。當然,他們應該有對過程的控制權。畢竟,他們正為它付出努力,他們正為它提供需求,而且完成的產品必須使他們滿意。但業務極少驅動軟件。技術人員很快會告訴業務人員軟件是“軟”的,但同樣是這些技術人員卻抵制變化,因為變化是痛苦的和代價很高的。程序員不希望沒等到軟件變得完美就發布它,而業務人員則不希望新軟件給用戶造成過多破壞,因此雙方共同使得發行不及時 — 有時是在項目開始的數年之后才發行。

    在這一周期結束時最終得到的并不是企業需要的軟件 — 它是企業在項目開始時認為它所需要的。大多數客戶都沒有興趣購買這樣的“陳年”軟件,但這卻是他們所得到的。技術人員不希望交付這樣的軟件,但他們認為自己別無選擇。每個人都感到挫折、疲倦、憤怒和上當受騙。

    參與創作軟件的每個人在這一過程的某些環節都妥協過;蛟S是為了保住飯碗或使沖突減到最小;蛟S是因為宿命論悄然涌上心頭并在您毫無察覺的情況下影響了您;蛟S是因為懶惰。無論是什么,每個人都做了一個糟糕的決定。每個人都覺得使事情保持現狀好過嘗試使事情有所不同。遺憾的是,只有改變才能使事情做得更好。我們需要回到那條路上。出發的最佳地點之一就是客戶行為。

    學會驅動

    軟件開發在過去三十年里已經是非常一致。當然,在其發展過程中有過一些改進,但基本主題是相同的:

    用戶并不真正知道他們想要什么,所以開發人員必須告訴他們以便生產軟件。


    變化有害,所以應不惜一切代價來禁止它。


    禁止變化的方法是在一開始把所有的事情寫在紙上,找些人在上面簽字核準,然后照這個計劃執行。


    在一開始就定義所有需求的唯一方法是讓業務人員提出一組需求,在末期試用完成的產品以確認每樣事情都和這些需求一致,而在中期則置身事外。 
    結果是大多數軟件項目生產(如果它們確實生產了某些東西)的是某個人在開始時認為他想要的軟件,而不是軟件用戶在末期最終想要的。我們最終得到的是我們根本不想要的東西,但似乎沒有辦法能走出這個怪圈。管理人員不能只是規定變化。這在過去從未奏效,將來也不會。為什么我們會深陷于此,我們該做些什么?

    首先,身為 XP 客戶的人需要起到客戶的作用。什么人能成為客戶?通常是具有足夠領域和最終用戶知識、能對特性的優先級作出困難決定的人。他可能是了解用戶真正需要的超級用戶。他可能是了解市場需求和競爭對手情況的市場銷售人員。他一般不會是順理成章就獲得這一職位的經理,盡管這也許總比沒有客戶要好。必須有人接受該職位并承諾做好這項工作。

    第二,任何接受客戶職位的人都必須把自己當作團隊的一份子。他必須愿意花必要的時間和團隊其他成員一起生產正確的軟件?蛻舨荒茴A先說明需求后就離開,若軟件失敗則依靠難以自圓其說的推諉伎倆來為自己掩護?蛻舨荒茉趫F隊其他人叫他離開叫他不要制造麻煩時勉強同意。他不是在制造麻煩;他是在為團隊指明方向。

    第三,客戶必須暫時把懷疑放到一旁,盡力表現得好象讓團隊探索生產最終產品的方法會比預先規定每一項事情取得更好的結果。這對于程序員和客戶都很難。程序員希望不被方法的每一步所困擾就能生產出優秀的軟件。他們認為預先說明每項事情并且不背離規范就能確保這一點?蛻粢矒。他們希望寫進每一個可能的需求(包括他們并不真正需要的需求),以便在不得不放棄時給自己留有更多商議的余地。這些觀點沒有一條有助于團隊生產優秀軟件?蛻粜枰f明軟件真正需要什么,什么是最重要的。然后,他們必須相信程序員(是的,很難做到的一件事)會朝著那個目標堅持不懈地工作。當然,程序員必須通過言出必行來贏得更多信任。這對每個人都有風險,但卻是做事的典型方法。采用 XP,風險是顯而易見的,而不是被成堆的紙張和承諾所隱藏。

    第四,客戶必須改變他們考慮軟件的方式。如何才能知道真正需要什么軟件?我只知道兩種方法:猜測并指望猜對,或者一點一點地交付軟件并在更好地理解了客戶的真正需要時對軟件進行調整;ù罅繒r間讓人們討論他們需要的軟件而不實際使用軟件只是第一種方法的翻版。人就是人。讓他們使用計算機并不能改變這一點。真正理解需求的唯一方法是有一個運行的示例,兩方的團隊成員都可以用它找到共同點:“這里,看到這個了嗎?那根本就不是我想要的。那個東西的位置真是糟透了,非常礙事!那里可以更好些。不過這個,這個真是太好了!狈答伿欠浅V匾,所以團隊應及早且經常地發表反饋。坐等軟件變得“完美”只會推遲您猜錯的壞消息。

    如果這就是客戶所要做的全部,那有什么問題?事情不止那么簡單。事實上,它太難了,以至于大多數人都不愿做它。即使他們愿意做,也不能做。大多數組織在建立時都不允許這樣的過程發生。使用 XP 制作軟件會遇到強大的抵制,因為一些有權利的人對于這是否明智有正統的考慮 — 并且因為一些有權利的人很頑固。

    組織可能成為問題
    如果 XP 客戶所在的組織不同意使用 XP,那么他不能做他的工作。這意味著兩件事情:

    必須存在 XP 團隊以便將客戶包括在內。 
    客戶的上司必須讓客戶成為該團隊的一部分。 

    團隊必須在 XP 客戶能夠做他的工作之前就在使用 XP。如果團隊在假裝使用 XP,或限制客戶充當那一角色的能力,則 XP 不會起作用。遺憾的是,大多數組織的建立機制與 XP 是對立的,這種對立或是有意識的或是自然形成的。除非組織中至少有一小部分愿意嘗試 XP,否則它不會起作用。但您可以從小做起。一位客戶,幾個開發人員和一個小小的應用程序就是您需要的全部。如果那個團隊生產出優秀的產品,則有可能其他團隊將采取一些那樣的行為。

    如果 XP 團隊需要某位客戶,而該預期客戶的上司卻不允許他在該團隊上花任何時間,那會怎么樣?那樣的話,這個項目從一開始就注定要失敗。如果團隊需要客戶參與計劃會議或試用最新的應用程序,但該客戶卻始終忙于填寫 A-324-XYZ 報告以應付即將到來的每兩周一次的形勢通告會,那么該團隊將不能交付他們所承諾的東西。沒有某位相似領域的專家,您就無法有效地研究,而那位專家就是客戶。組織中控制客戶時間的人必須放棄部分要求。

    大多數組織的建立機制使這幾乎不可能。那么我們就永遠深陷下去嗎?也許,但我不認為我們必須如此。改變這種情形只需要勇氣。

    進行改變的勇氣
    坦率地講,我認為有三個原因共同促使公司的 IT 人員陷入這個怪圈:

    習慣 
    懦弱 
    缺乏遠見 
    打破習慣是很難的。您甚至沒有考慮過這么做。習慣是您生活中很自然的一部分,即使某些清醒的情況下您知道不應那樣行事。這就是為什么人們會抽煙、暴食或對著他們的孩子大喊大叫。一旦您有了某種習慣,打破它就需要有意識的努力。大多數公司生產軟件的方法直接來源于該公司各成員的習慣。

    有些公司的很多人都沒有膽量。當事情真正有麻煩,并且他們真正意識到組織走向了錯誤方向時,他們要么屈服要么走人。此刻,如果留在某個組織中的日子確實很糟糕,而且您盡了最大努力也無法改善它,那就可能是離開的時候了,對于這種情況,我將第一個贊成。但一看到阻力就逃跑并不是解決問題的辦法。您是在逃避必然性。您跑到別的某個地方,在那里相似的問題突然再次出現,而您又會離開那個新地方。組織不會改變有什么奇怪呢?每個人都跑開而使它們支離破碎。

    我們需要的是新一代的公司領導(既有技術型也有非技術型),他們將站起來說真話 — 即使要面對傳統和習慣。緩和與退卻的戰略根本不起作用。非技術型領導必須擔當 XP 團隊的客戶,并且如有必要應該用全部時間參與。技術型領導必須愿意放棄控制規范的權利,并探索制作優秀軟件的方法。

    我們需要更多勇敢的人,但光有勇氣沒有遠見也不能成事。對理想的狀況有遠見并有勇氣嘗試達到那一狀況,我們需要的是這樣的人。在真正的 XP 方式中,這種遠見在我們朝向它前進時會改變,但我們必須前進。

    軟件開發讓人痛苦而產品成為垃圾,這是因為您我允許它這樣。這是我們的過失。責備“那些人”或“那個組織”起不了任何作用,只會無限期延長這一循環。我們需要痛定思痛,要求變革,并首先自己做好表率。做到那一點非常困難。最后,一言以蔽之:您是希望混日子領工資,還是希望改變世界?

    延伸閱讀

    文章來源于領測軟件測試網 http://www.kjueaiud.com/


    關于領測軟件測試網 | 領測軟件測試網合作伙伴 | 廣告服務 | 投稿指南 | 聯系我們 | 網站地圖 | 友情鏈接
    版權所有(C) 2003-2010 TestAge(領測軟件測試網)|領測國際科技(北京)有限公司|軟件測試工程師培訓網 All Rights Reserved
    北京市海淀區中關村南大街9號北京理工科技大廈1402室 京ICP備10010545號-5
    技術支持和業務聯系:info@testage.com.cn 電話:010-51297073

    軟件測試 | 領測國際ISTQBISTQB官網TMMiTMMi認證國際軟件測試工程師認證領測軟件測試網

    老湿亚洲永久精品ww47香蕉图片_日韩欧美中文字幕北美法律_国产AV永久无码天堂影院_久久婷婷综合色丁香五月

  • <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>