應(yīng)用敏捷方法到非軟件企業(yè)項目

2019-5-20 / 已閱讀：2590 / 上海邑泊信息科技

        敏捷項目管理技術(shù)已成為 IT 項目管理中增長最快、最受歡迎的方面之一。在軟件開發(fā)中使用敏捷技術(shù)可以使完成的機會較低的項目和能夠非常迅速地交付結(jié)果并隨著時間的推移繼續(xù)交付結(jié)果的項目之間的差異。然而, 敏捷思維從來都不是被設(shè)計為僅限于軟件開發(fā)。從一開始就預(yù)見將這一項目管理概念應(yīng)用于流程和其他類型的項目。本文介紹了如何將軟件開發(fā)中使用的敏捷技術(shù)應(yīng)用于企業(yè)項目附帶的變更管理過程。

        企業(yè)項目的主要挑戰(zhàn)之一是它可能在組織中引起的變化的深度。一個常見的陷阱是制定一個全面的計劃, 然后推動立即部署整個計劃。將敏捷思維應(yīng)用于變革管理項目是一個很好的契合。

        敏捷項目管理使我們首先從戰(zhàn)略層面的大目標(biāo)角度來思考一個項目, 然后在戰(zhàn)術(shù)層面上讓我們從交付生產(chǎn)就緒的結(jié)果的角度來思考。

        企業(yè)項目有能力對組織的有效性進(jìn)行量化改進(jìn), 但它們也有可能很難管理。在接下來的幾頁中, 我們將討論如何使用軟件開發(fā)項目中更常見的敏捷技術(shù)管理企業(yè)項目。

        什么是企業(yè)項目？

        企業(yè)項目是影響整個企業(yè)運營的項目。企業(yè)項目可以是系統(tǒng)項目。更換本組織的財務(wù)制度肯定是有條件的。財務(wù)制度不僅影響到會計部門。它可以影響我們的購買方式、銷售方式、跟蹤客戶、營銷方式以及如何維持庫存或交付產(chǎn)品。但企業(yè)項目不需要與軟件有關(guān)。一個組織的總部從一座大樓搬遷到另一棟樓肯定是有資格的。收購企業(yè)肯定是有條件的。設(shè)立項目管理辦公室 (PMO) 幾乎總是符合條件。

        企業(yè)項目的一個關(guān)鍵特征是涉及文化變革。預(yù)計該項目將導(dǎo)致組織中人員行為的變化。企業(yè)項目幾乎總是被低估。

        無論這樣一個項目有多詳細(xì), 企業(yè)項目的復(fù)雜性幾乎總是被低估。該項目的性質(zhì)使這幾乎不可避免。當(dāng)項目將導(dǎo)致行為變化時, 可以肯定的是, 隨著項目的發(fā)展, 受影響的人將以不斷變化的視角看待項目。就像問別人方向、得到回復(fù)的老生常談: "你不能從這里到達(dá)那里" 一樣, 企業(yè)項目在進(jìn)展順利之前, 幾乎總是無法完全評估。

        因此, 在開始之前似乎完全合理的估計成為改變對該系統(tǒng)真正要求的看法的受害者。這可能會在項目后期產(chǎn)生重大影響, 因為時間表和預(yù)算面臨壓力, 更糟糕的是, 范圍在悄然而至.

        企業(yè)項目可能需要花費大量的時間和很大比例的企業(yè)預(yù)算。這使得它成為那些試圖完成自己項目的人的一個明顯目標(biāo)。不管是什么問題, 都可以用技術(shù)來解決。

        在我們的現(xiàn)代, 我們對技術(shù)有如此大的依賴, 認(rèn)為無論我的企業(yè)面臨什么挑戰(zhàn), 都必須有技術(shù)上的答案, 這可能有點太容易了。更糟糕的是, 如果企業(yè)項目涉及技術(shù), 項目很快就會成為關(guān)于技術(shù)的項目, 而不是項目設(shè)計要交付的解決方案。

        因此, 財務(wù)系統(tǒng)的變化變成了 Oracle 或 SAP 項目。對集中式項目管理辦公室的更改將成為 Microsoft 項目服務(wù)器。

        這是一個很容易陷入的陷阱。我多次被問到: "你能幫助我們實施企業(yè)項目管理軟件嗎？""你為什么需要它？"我總是回答。一半以上的時間, 這個人都不知道。闡明我們的問題是什么, 企業(yè)項目將提供什么解決方案, 可以使項目保持在正確軌道上。

        管理層已經(jīng)過去。他們不是嗎？

        也許不會。執(zhí)行發(fā)起人通常低估企業(yè)項目的影響。因此, 管理層可能不明白你會改變企業(yè)文化, 這可能會導(dǎo)致不安。認(rèn)為管理層完全了解在項目關(guān)鍵時刻需要多少資金來幫助人員加入是不明智的。在以協(xié)商一致方式管理為規(guī)則的文化中, 這可能是最具挑戰(zhàn)性的。一個幸福的大家庭在企業(yè)項目的發(fā)展中歡呼的共識并不常見。

        大爆炸部署

        這一切都會在某一天走到一起, 這是企業(yè)項目中風(fēng)險最高的陷阱之一。我們的想法是, 我們將做一個大規(guī)模的設(shè)計。我們會計劃好每一個細(xì)節(jié)。我們會像倉鼠一樣在車輪上工作, 然后, 在未來某個神奇的時刻, 在某一天, 我們會拋出一個開關(guān), 解決方案將打開并開始交付結(jié)果.

        組織受企業(yè)影響越多, 此路徑的風(fēng)險就越大。每天這個項目都是不完整的, 它就像一場風(fēng)暴即將到來, 為那些即將受災(zāi)的人而隱約出現(xiàn)。這使得項目面臨巨大風(fēng)險。每天它都在進(jìn)步, 會發(fā)生一些事情。贊助商可以更改。這家公司可以出售。這家公司可以買另一家公司。這個行業(yè)可以改變。經(jīng)濟(jì)可以改變。在這段時間里, 項目的好處只是理論上的.

        而且, 即使這個奇妙的日子確實在項目交付時到來, 但可以肯定的是, 在那一天, 會有人說: "哦, 但這不是我們真正想要的"

        那是一個企業(yè)項目。但企業(yè)項目的界定并不是本文的主題。

        什么是敏捷？

        這篇文章是關(guān)于敏捷方法的, 所以現(xiàn)在是我們把注意力轉(zhuǎn)向敏捷的意義的時候了。在《敏捷軟件開發(fā)宣言》出版后, 敏捷一詞于2001年開始流行。1 7 個開發(fā)者在猶他州開會, 討論如何改進(jìn)軟件開發(fā)過程, 結(jié)果是在右邊看到了這個文本。

        是的, 這就是整個宣言。想到這少量的文本是如何影響項目管理社區(qū)的, 真是不可思議。在這幾個詞中, 有標(biāo)準(zhǔn)、原則、方法和如何實施這種哲學(xué)的計劃。你可能聽說過敏捷的許多迭代中的一個, 它的術(shù)語包括理性或 (理性統(tǒng)一流程的簡稱)、Scrum、極端編程 (或 XP)。

        展品 1-敏捷清單1

        從本質(zhì)上講, 敏捷是將項目開發(fā)為一個迭代過程, 而不是一個預(yù)先設(shè)定的計劃。而這在2001年并不是什么新鮮事。要真正理解敏捷, 我們應(yīng)該考慮它的一些前輩。

        敏捷的歷史

        如果我們想想到2001年之前的軟件行業(yè),不難想象一些頂級開發(fā)人員通常會對通常應(yīng)用于大規(guī)模軟件開發(fā)的項目管理感到沮喪。在歲月 1995年到2000年 Y2K 現(xiàn)象控制了軟件產(chǎn)業(yè)。人們擔(dān)心, 近50年的軟件開發(fā), 日期條目以兩個字符為代表, 會導(dǎo)致現(xiàn)代文明崩潰, 因為世界各地的各種規(guī)模的組織都在爭先恐后地改變他們的關(guān)鍵系統(tǒng).

        從世界上最大到最小的公共和私營部門的組織都參與其中。大型金融機構(gòu)或市政、地區(qū)或國家政府部門的軟件項目可以是大規(guī)模的、多年的努力。我記得我個人參觀了紐約市一家跨國公司的項目辦公室。他們給了我一個他們所面臨的一些挑戰(zhàn)的例子: "例如, 我們有一個很小的軟件, 從我們的銀行到美聯(lián)儲 (美國聯(lián)邦儲備銀行)," 我的主人解釋說。"它根據(jù)其他系統(tǒng)中的一套嚴(yán)格管理的標(biāo)準(zhǔn)來回轉(zhuǎn)移資金。我們知道軟件。它是多年前制造的。我們或多或少知道它的作用, 但該軟件的源代碼早已丟失?，F(xiàn)在想象一下我們面臨的挑戰(zhàn)是, 反向工程這一小部分代碼, 創(chuàng)建一個設(shè)計, 重新編寫代碼, 然后對其進(jìn)行測試, 以確保它完美地工作。她引起了我的注意。這是一個充滿此類項目的項目中的一個小項目, 實際上成千上萬的人正在他們的組織內(nèi)從事這類工作.

        這一波緊張的發(fā)展一直持續(xù)到千年結(jié)束, 令人欣喜的是, 世界并沒有結(jié)束。許多項目和項目都是不完整的, 直到 2 0 0 0年年中, it 行業(yè)的許多人才能夠深呼吸并進(jìn)行評估.

        對許多人來說, 設(shè)計的項目管理風(fēng)格, 在這個設(shè)計中, 我們可能會想到的企業(yè)所需的每一點范圍都被降級為舊思維, 那些擁抱敏捷的人稱之為 "瀑布", 指的是 GANTT 圖表的方式只有在完成后, 才會看到一個任務(wù)被下一個任務(wù)成功。

        因此, 2001年人們非常希望研究如何創(chuàng)建這些項目并更有效地交付成果。但這17個開發(fā)人員有許多項目管理示例可供參考.

        快速應(yīng)用程序設(shè)計 (RAD) 是敏捷的前兆。這一理念也專注于軟件開發(fā), 并在20世紀(jì)80年代和90年代流行。RAD 的基本意圖是, 在工作開始之前, 設(shè)計不必完整。當(dāng)時的想法是, 隨著軟件項目的發(fā)展, 項目參與者在研究一些已經(jīng)在工作的軟件時, 將能夠完善他們的設(shè)計思維。

        這種 RAD 思維擴(kuò)展了一個在工程和建筑行業(yè)已經(jīng)很有名的主題, 稱為設(shè)計-建造。

        設(shè)計-建造概念在20世紀(jì)80年代中期和90年代初開始流行。偏離設(shè)計的概念, 然后投標(biāo), 然后建造, 設(shè)計-建造項目是一個設(shè)計-建設(shè)項目, 其中一個大的超強設(shè)計將在一個高水平, 然后更詳細(xì)地為建筑的早期元素。隨著項目的發(fā)展, 設(shè)計師和客戶將共同努力, 完善設(shè)計的概念和結(jié)構(gòu)。這在更早的項目管理思維中也有其一些根源, 即滾滾波.

        滾滾波計劃是個人的最愛。項目的時間表是在摘要級別制定的, 就在它旁邊, 項目的近期計劃要詳細(xì)得多。

        所有這些概念的共同點是, 在項目開始之前, 沒有一個完整的剛性時間表。雖然這可能是某些類型的項目所需要的, 但企業(yè)項目尤其不適合嚴(yán)格的時間表。這類項目的時間表也不可信.

        這種敏捷的東西真的管用嗎？

        是的, 它可以。許多 IT 組織都將敏捷方法作為管理開發(fā)項目的主要方法。在我們遇到的大多數(shù)組織中, 更傳統(tǒng)的調(diào)度和項目管理的混合環(huán)境與敏捷技術(shù)并存, 而敏捷技術(shù)更有可能應(yīng)用于戰(zhàn)術(shù)層面.

        使用此方法的組織最明顯的好處是可使用功能的迭代發(fā)布。隨著每一塊的完成, 客戶開始看到開發(fā)的回報, 隨著項目的進(jìn)展, 開發(fā)的深度和豐富度也會增加。

        這些環(huán)境中不太明顯但更重要的一個方面是, 客戶自然成為設(shè)計的一個組成部分, 隨著項目的進(jìn)展, 他們越來越多地與開發(fā)團(tuán)隊合作, 他們可以看到并評論他們收到的內(nèi)容。

        如果我們應(yīng)用同樣的思維, 我們幾乎可以在任何項目中利用這一點。

        我們不建議將您的整個項目管理辦公室轉(zhuǎn)變?yōu)榉擒浖椖康膬H針對 agile 的環(huán)境。事實上, 即使在純軟件項目管理辦公室, 常見的項目管理技術(shù)幾乎總是與敏捷技術(shù)共存。

        以這種方式實現(xiàn)敏捷意味著您不會放棄現(xiàn)有的項目管理流程, 但項目執(zhí)行方式的性質(zhì)最終會發(fā)生巨大的變化。

        選擇要在其他上下文中應(yīng)用的敏捷方面

        以下是一些可應(yīng)用于企業(yè)項目的更流行的敏捷實踐:

        積壓

        積壓是將成為最終交付項目一部分的功能和特性。將此視為大量的作用域項集合, 這些項目已被描述為它們對最終用戶意味著什么。然后, 這些積壓工作項在一個稱為 sprint 的很短的時間范圍內(nèi)分配給少量工作集中的資源。

        沖刺

        沖刺是一個短暫的迷你項目, 持續(xù)幾天。放置到?jīng)_刺中的所有任務(wù) (積壓項目) 都應(yīng)在沖刺持續(xù)時間內(nèi)完成。企業(yè)項目中這種方法的偉大之處在于, 工作是嚴(yán)格管理的, 但在沖刺本身, 團(tuán)隊覺得他們有很大的自由。另外, 在實踐中也有結(jié)構(gòu)上的緊張, 以完成你的所有工作。人們傾向于在這些環(huán)境中努力工作, 而不是團(tuán)隊中唯一一個在沖刺結(jié)束前工作沒有完成的團(tuán)隊.

        而且, 較短的任務(wù)通常管理得更好。

        跨職能團(tuán)隊

        敏捷中跨職能團(tuán)隊的概念很容易轉(zhuǎn)移到其他類型的項目。在一些項目中, 團(tuán)隊將在孤立的部門工作, 只在指定的時刻出來合作。軟件開發(fā)人員由此發(fā)現(xiàn)的挑戰(zhàn)是, 在這些指定的時刻, 孤立的團(tuán)隊沮喪地發(fā)現(xiàn), 他們的工作與其他團(tuán)隊的想法是相互矛盾的, 或者一些工作被其他團(tuán)隊冗余復(fù)制。讓一個跨職能的團(tuán)隊減少了孤島和由此產(chǎn)生的效率低下之間的障礙, 即讓不同的職能專家都團(tuán)結(jié)在一起。一個跨職能的團(tuán)隊以更高的效率運作, 并有一個更奇異的焦點.

        在企業(yè)重組項目、企業(yè)并購項目或企業(yè)辦公室搬遷項目中, 這種結(jié)構(gòu)運作良好是不容易想象的。

        持續(xù)集成

        就像我們認(rèn)為跨職能團(tuán)隊在整個項目中走到一起一樣, 持續(xù)集成意味著來自不同組的項目元素應(yīng)該持續(xù)地組合在一起, 這樣項目中的任何一個元素都不會成為筒 倉。讓我們以企業(yè)項目為例, 移動1000人的辦公室。一個小組可能在研究室內(nèi)辦公家具, 而另一個小組則在研究辦公室計算機網(wǎng)絡(luò)。在傳統(tǒng)的項目管理思想中, 很容易想象這樣一種情況, 即這些群體在這個過程的后期才會把圖紙放在一起, 卻發(fā)現(xiàn)他們有沖突。在這種工作不斷發(fā)展的過程中, 將這種工作結(jié)合起來通常要有效得多。

        信息散熱器

        這是一個很好的名字, 顯示項目信息, 它是相當(dāng)懷舊的我們這些誰一直在項目管理 3 0年或更長時間。在 20世紀(jì)80年代, 項目辦公室的 "戰(zhàn)爭室" 有地板到天花板的白色板, 有些在網(wǎng)格上涂上淺藍(lán)色的線條, 這樣卡片就可以用磁鐵卡在板子上, 為項目制作網(wǎng)絡(luò)圖。當(dāng)電腦軟件出現(xiàn)時, 這個手動過程看起來有些陳舊, 但擁有這些房間有一個美妙的方面。團(tuán)隊定期聚集在房間里更新他們的項目或他們的項目, 因此, 不僅定期看到項目的其他方面, 而且與整個團(tuán)隊的其他成員進(jìn)行溝通?；谟嬎銠C的系統(tǒng)導(dǎo)致許多這種社會交往消失, 項目失去了難以復(fù)制的合作關(guān)鍵要素。

        迭代和增量開發(fā)

        這是敏捷的基本方面之一, 對所有類型的企業(yè)項目都非常有用。企業(yè)項目的特點往往是難以事先準(zhǔn)確預(yù)測。在項目參與方看到項目早期的決定和設(shè)計之前, 項目后面的一些范圍幾乎無法估計。因此, 對于這類項目來說, 試圖進(jìn)行大規(guī)模的預(yù)測往往是很高的風(fēng)險。相反, 開發(fā)早期階段和返回以反復(fù)完善設(shè)計的適應(yīng)性方法可能會有效得多?；氐健俄椖抗芾碇R體系指南》 (PMBOK？指南) 有可能提供巨大的好處。

        Scrum 會議

        Scrum 會議是跨職能團(tuán)隊與主持人 (稱為 ScrumMaster) 會面的會議。該組更新其最后一次任務(wù)沖刺的進(jìn)度, 并為下一個沖刺重新組合。范圍取自未完成的功能、任務(wù)和問題的積壓, 并由團(tuán)隊成員分配或通過, 他們承諾在現(xiàn)有或即將進(jìn)行的沖刺的未來短時間內(nèi)執(zhí)行他們將執(zhí)行的操作。

        Scrum 會議的最大之處在于, 并不是橄欖球運動員們采用的名字, 而是會議的舉行方式.首先是, 他們幾乎總是幸福的快。由于這個項目已經(jīng)從一個不面對的巨大畫面分解為一個濃縮的沖刺, 所以更容易集中注意力。最后, 主持人的一個標(biāo)準(zhǔn)是不要成為參與者。這就形成了一個不參與的裁判, 他可以讓項目繼續(xù)向前推進(jìn)。即使是人們正在做出的承諾, 也是在未來幾天內(nèi)對少數(shù)項目做出的。沖刺的結(jié)局總是指日可待的, 即使是在第一天, 這也會產(chǎn)生將項目速度保持在非常高的水平的效果.

        與傳統(tǒng)的時間表不同的是, 在這個時間表中, 很容易被騙去思考, 它是項目的早期, 并且有無限的時間, 沖刺讓你像項目一樣運作只有短短幾天的時間。這類能源具有傳染性, 如果得到適當(dāng)?shù)闹笇?dǎo), 就會產(chǎn)生很高的生產(chǎn)力。

        時間裝箱

        時間裝箱是一個術(shù)語, 是那些對傳統(tǒng)項目管理感興趣的人非常熟悉的。它需要一個工作范圍, 并把它放到一個時間表中--一個時間的盒子。那些熟悉傳統(tǒng)關(guān)鍵路徑方法調(diào)度的人默認(rèn)情況下會這樣想。那些在以農(nóng)業(yè)為中心的項目管理環(huán)境中長大的人會發(fā)現(xiàn)這是例外, 而不是常規(guī)。然而, 重要的是不要放棄我們傳統(tǒng)的項目管理方式。無論您在為非軟件項目采用敏捷實踐方面走多遠(yuǎn), 都將始終有一個地方可以使用在項目管理行業(yè)中享有盛譽的技術(shù)和實踐按時、按預(yù)算交付。

        使用案例

        敏捷用例是描述某人將如何完成函數(shù)的一種非常常用的方法。此技術(shù)在幾乎任何過程驅(qū)動的項目中都非常有用。項目經(jīng)理通常會有一個用標(biāo)題描述的過程, 如果幸運的話, 還有一個敘述, 但在描述用例時, 要完成的步驟是一個接一個地列出的,最終的結(jié)果是完成這個過程。以這種方式描述一個過程可以消除對預(yù)測的實踐的許多潛在陷阱。不難想象, 這在企業(yè)重組、辦公室搬遷或任何企業(yè)流程的改變中會有多大的用處.

        當(dāng)這種技術(shù)沒有使用時, 一個過程的實施很有可能只有在最后一刻才能發(fā)現(xiàn)一個對組織至關(guān)重要的基本和關(guān)鍵的程序。項目延誤或更嚴(yán)重的項目中斷對企業(yè)的可能性可能很大。

        用戶故事

        如果用例描述了一個過程和完成該過程所需的步驟, 則用戶情景是業(yè)務(wù)問題的敘述。在非敏捷項目中, 這種類型的文檔往往不存在, 然而, 它是至關(guān)重要的。用戶情景概述了更改發(fā)生的根本目的。遺憾的是, 非常常見的是看到一個項目正在實施解決方案, 而沒有對問題是什么有一個根本的了解。在我們的實踐中, 我們經(jīng)常聽到客戶的請求, 將解決方案描述為他們的問題。

        "商業(yè)挑戰(zhàn)或問題是什么？" 我們會問.

        "問題是, 我們需要部署一個企業(yè)項目管理系統(tǒng)," 客戶會做出回應(yīng).

        "不," 我們會說。"部署 EPM 系統(tǒng)是解決某些問題的辦法, 而不是問題。根本問題是什么？ "

        創(chuàng)建用戶情景時, 您將用簡單的語言描述問題是什么以及如何克服。如果您希望管理項目已完成, 這是一個顯而易見的要求。對項目經(jīng)理來說, 還有什么比這更重要的呢？

        大爆炸與分階段方法部署

        敏捷思維的基本原則之一是我們多年來在企業(yè)項目實施中推廣的東西; 分階段方法的好處。想想這兩個選項:

1. 大爆炸

        您的第一個選項是在項目周期結(jié)束時一次部署您的企業(yè)項目。首先你會被期望對項目必須交付的內(nèi)容做出極其準(zhǔn)確的預(yù)測。您必須假設(shè), 在此期間, 關(guān)鍵企業(yè)人員不會發(fā)生任何變化, 經(jīng)濟(jì)因素、環(huán)境因素、工業(yè)因素、競爭因素或任何其他可能影響項目要求的因素也不會發(fā)生變化。

        是的, 這是一個艱巨的任務(wù)。

        然后, 您需要生成針對結(jié)束日期的項目。在整個過程中, 項目更改的客戶端將不會獲得項目的任何好處。畢竟, 你最終會一次部署所有的東西。

        最后, 您需要提供項目的好處, 假設(shè)參與原始規(guī)劃過程的每個人都完全記住他們所要求的內(nèi)容、他們的要求, 并且他們沒有想到任何新的請求。同時.

2. 分階段方法

        備選方案2的目標(biāo)是作為第一階段, 而不是能夠交付的最多的階段, 但最低限度: "我們能夠提供的最低范圍是多少, 其交付將帶來積極的投資回報？這是我們在創(chuàng)建分階段交付時提出的問題。重要的是要確保第一次迭代是有用和有用的, 客戶端不會將其扔掉。這樣做的好處是, 客戶會更快地收回價值, 盡管它只是最終預(yù)期價值的一小部分。

        更隱蔽但更關(guān)鍵的優(yōu)勢是, 客戶端將能夠在僅進(jìn)行第一次迭代后開始提供反饋, 而不必等到項目結(jié)束。當(dāng)然, 預(yù)期變化的可能性是巨大的, 但項目最終最終更符合客戶要求的可能性同樣巨大。

        當(dāng)然, 每一種方法都有好處。大爆炸方法更有可能實現(xiàn)最初設(shè)計的內(nèi)容。這是一個優(yōu)勢。大爆炸方法在提供任何價值之前也有更高的被取消的風(fēng)險。這是一個缺點。分階段的方法更有可能最終提供與最初打算不同的東西。這是一個缺點。一旦達(dá)到一定程度的收益遞減收益, 分階段辦法也更有可能被取消?？蛻艨梢?"足夠滿意" 的項目, 并取消其余的。這是一個缺點。有利的一面是, 分階段的方法更有可能提供客戶會滿意的東西, 并且更有可能提供價值, 因為它將在每個階段的發(fā)布時一次交付一點.

        潛在的陷阱

        我們已經(jīng)討論了敏捷技術(shù)和實踐, 以及如何將其中一些實踐應(yīng)用于非軟件項目?，F(xiàn)在可能是一個很好的時機, 可以對以這種方式采用敏捷提供一些潛在陷阱的警告。

        采用一切

        只是跳上敏捷的潮流, 說你會采用敏捷方法的各個方面、技術(shù)和實踐通常是不健康的。即使是軟件開發(fā)環(huán)境也是如此。如果您正在進(jìn)行企業(yè)文化變革, 請在迭代階段進(jìn)行更改。將敏捷思維應(yīng)用到敏捷技術(shù)的實施中。您需要從這些做法中挑選適合于特定情況的做法.

        放棄項目管理技能、思維和方法

        同樣, 即使是軟件開發(fā)項目也是如此。僅僅因為敏捷技術(shù)在這里有一定的價值, 我們是否應(yīng)該放棄關(guān)鍵路徑計劃、風(fēng)險分析和質(zhì)量控制？絕對不行。項目管理辦公室的最佳方案是從特定情況下可用的方法、技術(shù)和做法中進(jìn)行選擇.

        大爆炸變化

        抵制同時做出改變的誘惑。如果您使用一種方法分階段實現(xiàn)這些技術(shù), 那么您將能夠更好地看到它們何時富有成效, 何時應(yīng)被采用, 何時不使用。

        封裝

        許多組織已經(jīng)開始將敏捷思維編織到他們的非 it 項目管理中, 正如您在前面的頁面中所看到的, 您也可以這樣做。不過, 和任何企業(yè)文化的變化一樣, 你會發(fā)現(xiàn), 辨別采用哪些技術(shù), 采用這些技術(shù)的速度有多快, 會更有效。

上一篇：私募股權(quán)價值，上市公司戰(zhàn)略轉(zhuǎn)型與業(yè)務(wù)創(chuàng)新利器
下一篇：上海文檔管理軟件怎么弄？