應用敏捷方法到非軟件企業項目
2019-5-20 / 已閱讀：2934 / 上海邑泊信息科技
敏捷項目管理技術已成為 IT 項目管理中增長最快、最受歡迎的方面之一。在軟件開發中使用敏捷技術可以使完成的機會較低的項目和能夠非常迅速地交付結果并隨著時間的推移繼續交付結果的項目之間的差異。然而, 敏捷思維從來都不是被設計為僅限于軟件開發。從一開始就預見將這一項目管理概念應用于流程和其他類型的項目。本文介紹了如何將軟件開發中使用的敏捷技術應用于企業項目附帶的變更管理過程。
企業項目的主要挑戰之一是它可能在組織中引起的變化的深度。一個常見的陷阱是制定一個全面的計劃, 然后推動立即部署整個計劃。將敏捷思維應用于變革管理項目是一個很好的契合。
敏捷項目管理使我們首先從戰略層面的大目標角度來思考一個項目, 然后在戰術層面上讓我們從交付生產就緒的結果的角度來思考。
企業項目有能力對組織的有效性進行量化改進, 但它們也有可能很難管理。在接下來的幾頁中, 我們將討論如何使用軟件開發項目中更常見的敏捷技術管理企業項目。
什么是企業項目？
企業項目是影響整個企業運營的項目。企業項目可以是系統項目。更換本組織的財務制度肯定是有條件的。財務制度不僅影響到會計部門。它可以影響我們的購買方式、銷售方式、跟蹤客戶、營銷方式以及如何維持庫存或交付產品。但企業項目不需要與軟件有關。一個組織的總部從一座大樓搬遷到另一棟樓肯定是有資格的。收購企業肯定是有條件的。設立項目管理辦公室 (PMO) 幾乎總是符合條件。
企業項目的一個關鍵特征是涉及文化變革。預計該項目將導致組織中人員行為的變化。企業項目幾乎總是被低估。
無論這樣一個項目有多詳細, 企業項目的復雜性幾乎總是被低估。該項目的性質使這幾乎不可避免。當項目將導致行為變化時, 可以肯定的是, 隨著項目的發展, 受影響的人將以不斷變化的視角看待項目。就像問別人方向、得到回復的老生常談: "你不能從這里到達那里" 一樣, 企業項目在進展順利之前, 幾乎總是無法完全評估。
因此, 在開始之前似乎完全合理的估計成為改變對該系統真正要求的看法的受害者。這可能會在項目后期產生重大影響, 因為時間表和預算面臨壓力, 更糟糕的是, 范圍在悄然而至.
企業項目可能需要花費大量的時間和很大比例的企業預算。這使得它成為那些試圖完成自己項目的人的一個明顯目標。不管是什么問題, 都可以用技術來解決。
在我們的現代, 我們對技術有如此大的依賴, 認為無論我的企業面臨什么挑戰, 都必須有技術上的答案, 這可能有點太容易了。更糟糕的是, 如果企業項目涉及技術, 項目很快就會成為關于技術的項目, 而不是項目設計要交付的解決方案。
因此, 財務系統的變化變成了 Oracle 或 SAP 項目。對集中式項目管理辦公室的更改將成為 Microsoft 項目服務器。
這是一個很容易陷入的陷阱。我多次被問到: "你能幫助我們實施企業項目管理軟件嗎？""你為什么需要它？"我總是回答。一半以上的時間, 這個人都不知道。闡明我們的問題是什么, 企業項目將提供什么解決方案, 可以使項目保持在正確軌道上。
管理層已經過去。他們不是嗎？
也許不會。執行發起人通常低估企業項目的影響。因此, 管理層可能不明白你會改變企業文化, 這可能會導致不安。認為管理層完全了解在項目關鍵時刻需要多少資金來幫助人員加入是不明智的。在以協商一致方式管理為規則的文化中, 這可能是最具挑戰性的。一個幸福的大家庭在企業項目的發展中歡呼的共識并不常見。
大爆炸部署
這一切都會在某一天走到一起, 這是企業項目中風險最高的陷阱之一。我們的想法是, 我們將做一個大規模的設計。我們會計劃好每一個細節。我們會像倉鼠一樣在車輪上工作, 然后, 在未來某個神奇的時刻, 在某一天, 我們會拋出一個開關, 解決方案將打開并開始交付結果.
組織受企業影響越多, 此路徑的風險就越大。每天這個項目都是不完整的, 它就像一場風暴即將到來, 為那些即將受災的人而隱約出現。這使得項目面臨巨大風險。每天它都在進步, 會發生一些事情。贊助商可以更改。這家公司可以出售。這家公司可以買另一家公司。這個行業可以改變。經濟可以改變。在這段時間里, 項目的好處只是理論上的.
而且, 即使這個奇妙的日子確實在項目交付時到來, 但可以肯定的是, 在那一天, 會有人說: "哦, 但這不是我們真正想要的"
那是一個企業項目。但企業項目的界定并不是本文的主題。
什么是敏捷？
這篇文章是關于敏捷方法的, 所以現在是我們把注意力轉向敏捷的意義的時候了。在《敏捷軟件開發宣言》出版后, 敏捷一詞于2001年開始流行。1 7 個開發者在猶他州開會, 討論如何改進軟件開發過程, 結果是在右邊看到了這個文本。
是的, 這就是整個宣言。想到這少量的文本是如何影響項目管理社區的, 真是不可思議。在這幾個詞中, 有標準、原則、方法和如何實施這種哲學的計劃。你可能聽說過敏捷的許多迭代中的一個, 它的術語包括理性或 (理性統一流程的簡稱)、Scrum、極端編程 (或 XP)。
展品 1-敏捷清單1
從本質上講, 敏捷是將項目開發為一個迭代過程, 而不是一個預先設定的計劃。而這在2001年并不是什么新鮮事。要真正理解敏捷, 我們應該考慮它的一些前輩。
敏捷的歷史
如果我們想想到2001年之前的軟件行業,不難想象一些頂級開發人員通常會對通常應用于大規模軟件開發的項目管理感到沮喪。在歲月 1995年到2000年 Y2K 現象控制了軟件產業。人們擔心, 近50年的軟件開發, 日期條目以兩個字符為代表, 會導致現代文明崩潰, 因為世界各地的各種規模的組織都在爭先恐后地改變他們的關鍵系統.
從世界上最大到最小的公共和私營部門的組織都參與其中。大型金融機構或市政、地區或國家政府部門的軟件項目可以是大規模的、多年的努力。我記得我個人參觀了紐約市一家跨國公司的項目辦公室。他們給了我一個他們所面臨的一些挑戰的例子: "例如, 我們有一個很小的軟件, 從我們的銀行到美聯儲 (美國聯邦儲備銀行)," 我的主人解釋說。"它根據其他系統中的一套嚴格管理的標準來回轉移資金。我們知道軟件。它是多年前制造的。我們或多或少知道它的作用, 但該軟件的源代碼早已丟失。現在想象一下我們面臨的挑戰是, 反向工程這一小部分代碼, 創建一個設計, 重新編寫代碼, 然后對其進行測試, 以確保它完美地工作。她引起了我的注意。這是一個充滿此類項目的項目中的一個小項目, 實際上成千上萬的人正在他們的組織內從事這類工作.
這一波緊張的發展一直持續到千年結束, 令人欣喜的是, 世界并沒有結束。許多項目和項目都是不完整的, 直到 2 0 0 0年年中, it 行業的許多人才能夠深呼吸并進行評估.
對許多人來說, 設計的項目管理風格, 在這個設計中, 我們可能會想到的企業所需的每一點范圍都被降級為舊思維, 那些擁抱敏捷的人稱之為 "瀑布", 指的是 GANTT 圖表的方式只有在完成后, 才會看到一個任務被下一個任務成功。
因此, 2001年人們非常希望研究如何創建這些項目并更有效地交付成果。但這17個開發人員有許多項目管理示例可供參考.
快速應用程序設計 (RAD) 是敏捷的前兆。這一理念也專注于軟件開發, 并在20世紀80年代和90年代流行。RAD 的基本意圖是, 在工作開始之前, 設計不必完整。當時的想法是, 隨著軟件項目的發展, 項目參與者在研究一些已經在工作的軟件時, 將能夠完善他們的設計思維。
這種 RAD 思維擴展了一個在工程和建筑行業已經很有名的主題, 稱為設計-建造。
設計-建造概念在20世紀80年代中期和90年代初開始流行。偏離設計的概念, 然后投標, 然后建造, 設計-建造項目是一個設計-建設項目, 其中一個大的超強設計將在一個高水平, 然后更詳細地為建筑的早期元素。隨著項目的發展, 設計師和客戶將共同努力, 完善設計的概念和結構。這在更早的項目管理思維中也有其一些根源, 即滾滾波.
滾滾波計劃是個人的最愛。項目的時間表是在摘要級別制定的, 就在它旁邊, 項目的近期計劃要詳細得多。
所有這些概念的共同點是, 在項目開始之前, 沒有一個完整的剛性時間表。雖然這可能是某些類型的項目所需要的, 但企業項目尤其不適合嚴格的時間表。這類項目的時間表也不可信.
這種敏捷的東西真的管用嗎？
是的, 它可以。許多 IT 組織都將敏捷方法作為管理開發項目的主要方法。在我們遇到的大多數組織中, 更傳統的調度和項目管理的混合環境與敏捷技術并存, 而敏捷技術更有可能應用于戰術層面.
使用此方法的組織最明顯的好處是可使用功能的迭代發布。隨著每一塊的完成, 客戶開始看到開發的回報, 隨著項目的進展, 開發的深度和豐富度也會增加。
這些環境中不太明顯但更重要的一個方面是, 客戶自然成為設計的一個組成部分, 隨著項目的進展, 他們越來越多地與開發團隊合作, 他們可以看到并評論他們收到的內容。
如果我們應用同樣的思維, 我們幾乎可以在任何項目中利用這一點。
我們不建議將您的整個項目管理辦公室轉變為非軟件項目的僅針對 agile 的環境。事實上, 即使在純軟件項目管理辦公室, 常見的項目管理技術幾乎總是與敏捷技術共存。
以這種方式實現敏捷意味著您不會放棄現有的項目管理流程, 但項目執行方式的性質最終會發生巨大的變化。
選擇要在其他上下文中應用的敏捷方面
以下是一些可應用于企業項目的更流行的敏捷實踐:
積壓
積壓是將成為最終交付項目一部分的功能和特性。將此視為大量的作用域項集合, 這些項目已被描述為它們對最終用戶意味著什么。然后, 這些積壓工作項在一個稱為 sprint 的很短的時間范圍內分配給少量工作集中的資源。
沖刺
沖刺是一個短暫的迷你項目, 持續幾天。放置到沖刺中的所有任務 (積壓項目) 都應在沖刺持續時間內完成。企業項目中這種方法的偉大之處在于, 工作是嚴格管理的, 但在沖刺本身, 團隊覺得他們有很大的自由。另外, 在實踐中也有結構上的緊張, 以完成你的所有工作。人們傾向于在這些環境中努力工作, 而不是團隊中唯一一個在沖刺結束前工作沒有完成的團隊.
而且, 較短的任務通常管理得更好。
跨職能團隊
敏捷中跨職能團隊的概念很容易轉移到其他類型的項目。在一些項目中, 團隊將在孤立的部門工作, 只在指定的時刻出來合作。軟件開發人員由此發現的挑戰是, 在這些指定的時刻, 孤立的團隊沮喪地發現, 他們的工作與其他團隊的想法是相互矛盾的, 或者一些工作被其他團隊冗余復制。讓一個跨職能的團隊減少了孤島和由此產生的效率低下之間的障礙, 即讓不同的職能專家都團結在一起。一個跨職能的團隊以更高的效率運作, 并有一個更奇異的焦點.
在企業重組項目、企業并購項目或企業辦公室搬遷項目中, 這種結構運作良好是不容易想象的。
持續集成
就像我們認為跨職能團隊在整個項目中走到一起一樣, 持續集成意味著來自不同組的項目元素應該持續地組合在一起, 這樣項目中的任何一個元素都不會成為筒 倉。讓我們以企業項目為例, 移動1000人的辦公室。一個小組可能在研究室內辦公家具, 而另一個小組則在研究辦公室計算機網絡。在傳統的項目管理思想中, 很容易想象這樣一種情況, 即這些群體在這個過程的后期才會把圖紙放在一起, 卻發現他們有沖突。在這種工作不斷發展的過程中, 將這種工作結合起來通常要有效得多。
信息散熱器
這是一個很好的名字, 顯示項目信息, 它是相當懷舊的我們這些誰一直在項目管理 3 0年或更長時間。在 20世紀80年代, 項目辦公室的 "戰爭室" 有地板到天花板的白色板, 有些在網格上涂上淺藍色的線條, 這樣卡片就可以用磁鐵卡在板子上, 為項目制作網絡圖。當電腦軟件出現時, 這個手動過程看起來有些陳舊, 但擁有這些房間有一個美妙的方面。團隊定期聚集在房間里更新他們的項目或他們的項目, 因此, 不僅定期看到項目的其他方面, 而且與整個團隊的其他成員進行溝通。基于計算機的系統導致許多這種社會交往消失, 項目失去了難以復制的合作關鍵要素。
迭代和增量開發
這是敏捷的基本方面之一, 對所有類型的企業項目都非常有用。企業項目的特點往往是難以事先準確預測。在項目參與方看到項目早期的決定和設計之前, 項目后面的一些范圍幾乎無法估計。因此, 對于這類項目來說, 試圖進行大規模的預測往往是很高的風險。相反, 開發早期階段和返回以反復完善設計的適應性方法可能會有效得多。回到《項目管理知識體系指南》 (PMBOK？指南) 有可能提供巨大的好處。
Scrum 會議
Scrum 會議是跨職能團隊與主持人 (稱為 ScrumMaster) 會面的會議。該組更新其最后一次任務沖刺的進度, 并為下一個沖刺重新組合。范圍取自未完成的功能、任務和問題的積壓, 并由團隊成員分配或通過, 他們承諾在現有或即將進行的沖刺的未來短時間內執行他們將執行的操作。
Scrum 會議的最大之處在于, 并不是橄欖球運動員們采用的名字, 而是會議的舉行方式.首先是, 他們幾乎總是幸福的快。由于這個項目已經從一個不面對的巨大畫面分解為一個濃縮的沖刺, 所以更容易集中注意力。最后, 主持人的一個標準是不要成為參與者。這就形成了一個不參與的裁判, 他可以讓項目繼續向前推進。即使是人們正在做出的承諾, 也是在未來幾天內對少數項目做出的。沖刺的結局總是指日可待的, 即使是在第一天, 這也會產生將項目速度保持在非常高的水平的效果.
與傳統的時間表不同的是, 在這個時間表中, 很容易被騙去思考, 它是項目的早期, 并且有無限的時間, 沖刺讓你像項目一樣運作只有短短幾天的時間。這類能源具有傳染性, 如果得到適當的指導, 就會產生很高的生產力。
時間裝箱
時間裝箱是一個術語, 是那些對傳統項目管理感興趣的人非常熟悉的。它需要一個工作范圍, 并把它放到一個時間表中--一個時間的盒子。那些熟悉傳統關鍵路徑方法調度的人默認情況下會這樣想。那些在以農業為中心的項目管理環境中長大的人會發現這是例外, 而不是常規。然而, 重要的是不要放棄我們傳統的項目管理方式。無論您在為非軟件項目采用敏捷實踐方面走多遠, 都將始終有一個地方可以使用在項目管理行業中享有盛譽的技術和實踐按時、按預算交付。
使用案例
敏捷用例是描述某人將如何完成函數的一種非常常用的方法。此技術在幾乎任何過程驅動的項目中都非常有用。項目經理通常會有一個用標題描述的過程, 如果幸運的話, 還有一個敘述, 但在描述用例時, 要完成的步驟是一個接一個地列出的,最終的結果是完成這個過程。以這種方式描述一個過程可以消除對預測的實踐的許多潛在陷阱。不難想象, 這在企業重組、辦公室搬遷或任何企業流程的改變中會有多大的用處.
當這種技術沒有使用時, 一個過程的實施很有可能只有在最后一刻才能發現一個對組織至關重要的基本和關鍵的程序。項目延誤或更嚴重的項目中斷對企業的可能性可能很大。
用戶故事
如果用例描述了一個過程和完成該過程所需的步驟, 則用戶情景是業務問題的敘述。在非敏捷項目中, 這種類型的文檔往往不存在, 然而, 它是至關重要的。用戶情景概述了更改發生的根本目的。遺憾的是, 非常常見的是看到一個項目正在實施解決方案, 而沒有對問題是什么有一個根本的了解。在我們的實踐中, 我們經常聽到客戶的請求, 將解決方案描述為他們的問題。
"商業挑戰或問題是什么？" 我們會問.
"問題是, 我們需要部署一個企業項目管理系統," 客戶會做出回應.
"不," 我們會說。"部署 EPM 系統是解決某些問題的辦法, 而不是問題。根本問題是什么？ "
創建用戶情景時, 您將用簡單的語言描述問題是什么以及如何克服。如果您希望管理項目已完成, 這是一個顯而易見的要求。對項目經理來說, 還有什么比這更重要的呢？
大爆炸與分階段方法部署
敏捷思維的基本原則之一是我們多年來在企業項目實施中推廣的東西; 分階段方法的好處。想想這兩個選項:
1. 大爆炸
您的第一個選項是在項目周期結束時一次部署您的企業項目。首先你會被期望對項目必須交付的內容做出極其準確的預測。您必須假設, 在此期間, 關鍵企業人員不會發生任何變化, 經濟因素、環境因素、工業因素、競爭因素或任何其他可能影響項目要求的因素也不會發生變化。
是的, 這是一個艱巨的任務。
然后, 您需要生成針對結束日期的項目。在整個過程中, 項目更改的客戶端將不會獲得項目的任何好處。畢竟, 你最終會一次部署所有的東西。
最后, 您需要提供項目的好處, 假設參與原始規劃過程的每個人都完全記住他們所要求的內容、他們的要求, 并且他們沒有想到任何新的請求。同時.
2. 分階段方法
備選方案2的目標是作為第一階段, 而不是能夠交付的最多的階段, 但最低限度: "我們能夠提供的最低范圍是多少, 其交付將帶來積極的投資回報？這是我們在創建分階段交付時提出的問題。重要的是要確保第一次迭代是有用和有用的, 客戶端不會將其扔掉。這樣做的好處是, 客戶會更快地收回價值, 盡管它只是最終預期價值的一小部分。
更隱蔽但更關鍵的優勢是, 客戶端將能夠在僅進行第一次迭代后開始提供反饋, 而不必等到項目結束。當然, 預期變化的可能性是巨大的, 但項目最終最終更符合客戶要求的可能性同樣巨大。
當然, 每一種方法都有好處。大爆炸方法更有可能實現最初設計的內容。這是一個優勢。大爆炸方法在提供任何價值之前也有更高的被取消的風險。這是一個缺點。分階段的方法更有可能最終提供與最初打算不同的東西。這是一個缺點。一旦達到一定程度的收益遞減收益, 分階段辦法也更有可能被取消。客戶可以 "足夠滿意" 的項目, 并取消其余的。這是一個缺點。有利的一面是, 分階段的方法更有可能提供客戶會滿意的東西, 并且更有可能提供價值, 因為它將在每個階段的發布時一次交付一點.
潛在的陷阱
我們已經討論了敏捷技術和實踐, 以及如何將其中一些實踐應用于非軟件項目。現在可能是一個很好的時機, 可以對以這種方式采用敏捷提供一些潛在陷阱的警告。
采用一切
只是跳上敏捷的潮流, 說你會采用敏捷方法的各個方面、技術和實踐通常是不健康的。即使是軟件開發環境也是如此。如果您正在進行企業文化變革, 請在迭代階段進行更改。將敏捷思維應用到敏捷技術的實施中。您需要從這些做法中挑選適合于特定情況的做法.
放棄項目管理技能、思維和方法
同樣, 即使是軟件開發項目也是如此。僅僅因為敏捷技術在這里有一定的價值, 我們是否應該放棄關鍵路徑計劃、風險分析和質量控制？絕對不行。項目管理辦公室的最佳方案是從特定情況下可用的方法、技術和做法中進行選擇.
大爆炸變化
抵制同時做出改變的誘惑。如果您使用一種方法分階段實現這些技術, 那么您將能夠更好地看到它們何時富有成效, 何時應被采用, 何時不使用。
封裝
許多組織已經開始將敏捷思維編織到他們的非 it 項目管理中, 正如您在前面的頁面中所看到的, 您也可以這樣做。不過, 和任何企業文化的變化一樣, 你會發現, 辨別采用哪些技術, 采用這些技術的速度有多快, 會更有效。
上一篇：私募股權價值，上市公司戰略轉型與業務創新利器
下一篇：上海文檔管理軟件怎么弄？