靈活項目管理
“成功有許多父親，而失敗是一個孤兒”，這是有思想的企業上司人經常引用的一句話。但是，當涉及失敗的靈活計劃時，舊的觀點可能會更新為：“成功是團隊的努力，而失敗隻是每個人的錯。”
沒有新的靈活計劃旨在失敗。然而，一個缺乏準備，資訊不靈通的團隊，将目光投向不切實際的目标，通常會從一開始就注定了項目失敗。
是否要確定您的靈活計劃會崩潰成一堆扭曲的希望和夢想？好了，這裡有七個簡單的步驟足以幹掉靈活：
靈活規劃
1.寬松而混亂地計劃
圍繞靈活性的偉大神話之一是規劃和結構并不是必不可少的。但這不是真的。“靈活不是混亂或沒有管理的借口，”提供項目管理和靈活服務的公司Project Management Essentials的創始負責人Alan Zucker說。
“規劃本質上是您的執行政策，” Creative Chaos的首席創新和技術官Umair Aziz指出。CreativeChaos是提供媒體制作，演員和活動設計服務的靈活采用者。“該政策常常含糊不清-太高而無法執行工程師-但使用可以分解為檢查清單的架構可以確定一緻性，并能不斷提醒您使給定項目保持進度。”
靈活釋出教育訓練（ART）是一種基本的計劃工具，可以使各個團隊适應共同的業務和技術任務。技術咨詢公司PSC Group的進階顧問兼業務經理Rod Cortez說：“進階管理層選擇的項目将為公司帶來最高的成本/收益。” 然後，靈活團隊會評估這些功能，并在sprint中計劃（在一定時間内必須完成特定工作并準備進行審查）。Cortez說：“有效地使用靈活開發方法的公司可以提前三到十二個月計劃功能和項目，并且成功率很高。”
不合作的團隊
2.組建一支不穩定且選拔不佳的團隊
團隊協作是成功實施靈活計劃的關鍵。阿齊茲說：“如果你們有一起工作的人，并且了解彼此的長處和短處，那麼與一群陌生人相比，您将擁有領先優勢。” “如果要組建一支嶄新的團隊，請引進對您的工作有明确興趣和激情的人。”
靈活管理平台供應商AgileCraft的首席執行官Steve Elliott說，人力資源和傳統團隊結構可能是一個棘手的問題，但是團隊之間的依賴關系是最終的靈活殺手。他指出：“有數十種方法可以使團隊保持一緻并分解工作以減少依賴關系，是以，為使團隊對團隊的依賴關系降到最低，值得我們付出很大的努力。” “戰略應用程式生命周期管理（ALM）工具可以幫助确定并提出優化團隊以減少依賴性的方法。”
祖克（Zucker）認為，所有靈活團隊都應自給自足。他說：“換句話說，他們不需要依靠其他專業團隊來完成他們的工作。” 他建議尋找通才的團隊候選人。紮克說：“新的行業術語是'T形'或'E形'資源。” “ T形資源具有專業知識或深度的領域，但也可以在其他技術領域工作。” 另一方面，E形資源擁有多個專業。
溝通障礙
3.盡可能少地進行秘密溝通
溝通屬性差的靈活團隊通常不會成功。紮克說：“靈活更喜歡在交流和資訊流持續不斷的地方的團隊。” “靈活希望與産品負責人以及團隊内部進行定期溝通。”
站起來和沖刺回顧之類的日常儀式提供了正确的最佳方法。阿齊茲說：“如果沒有疊代的路線修正，團隊将永遠不會變得更好。” “確定障礙已得到注冊并得到了妥善解決；確定在整個公司中共享所汲取的教訓。”
讓所有團隊成員和整個企業中的靈活團隊進行相同波長的交流也很重要。埃利奧特說：“将許多小組聚集在一起時，通常會以多種方式使用術語。” 為了使靈活項目成功定位，企業中的術語應統一。Elliott說：“靈活是首字母縮略詞，對于剛開始接受有限的靈活教育訓練的商務人士來說是一個困惑。” “如果這些團體不使用通用術語，那麼這一挑戰将會更加突出。”
項目
4.不完全了解項目的範圍或重點
與大多數傳統項目不同，靈活計劃的範圍不是一成不變的。紮克說：“對于靈活項目，産品負責人設定了願景和路線圖。” “願景和路線圖指導了開發過程。”
Zucker解釋說，該路線圖将分解為一系列增量建構，每個建構都為客戶提供價值。靈活團隊要開發的項目儲存在産品待辦事項清單中，該清單是要傳遞的東西的優先清單。每增加一次，團隊就會從清單的頂部拉出項目以傳遞給客戶。
從一開始，靈活項目就必須将企業的總體戰略（任務，願景，價值和目标）與實際完成的工作聯系起來。Elliott說：“這確定了傳遞的工作與戰略主題相關，如果沒有，那麼您可以迅速進行調整。” “使用可預測性分析和速度将有助于計劃經理适當地确定計劃增量計劃的範圍。”
測試
5.測試不善而随意
軟體顧問Tom Brusehaver說，測試絕對至關重要。他說：“進行單元測試将使開發人員更輕松地更改代碼。” “功能測試還可以幫助開發人員知道，當事物發生變化時會産生影響，也許更改需要調整，或者測試需要更改。” 內建測試也很關鍵。Brusehaver說：“通過較小的sprint-length增量，每個人都應該能夠放心，潛在的可傳遞産品将執行産品所有者/客戶希望的操作。”
許多靈活團隊使用測試驅動的開發實踐，其中測試用例在代碼之前編寫。“他們還使用自動化工具來最大化可以在代碼上運作的測試的數量，”紮克·天說道。“靈活還希望與産品負責人緊密合作，使團隊能夠準确傳遞預期的成果。”
不支援
6.無法赢得管理和員工支援
靈活的好處是顯而易見的，但是假設所有各方（尤其是企業上司者）将從一開始就加入董事會是錯誤的。埃利奧特說：“轉型非常昂貴，這給即時結果帶來了壓力。” “重要的是，在開始真正的靈活轉型之前，請確定組織高層支援它，可以赢得政治鬥争，并可以一遍又一遍地向團隊重複“為什麼”。”
赢得支援的最佳方法是證明靈活實際上會增加成功傳遞産品的幾率。金融安全咨詢公司Finserv Experts的常務董事Areiel Wolanow說：“已經在某些條件下對它進行了實證檢驗，但絕不應該将其視為理所當然。” “要獲得對靈活的支援，您需要說服利益相關者，對于特定程式而言，靈活成功的關鍵因素是正确的。”
解決員工和經理的擔憂也很重要，他們擔心靈活可能會對他們的職業産生負面影響。埃利奧特說：“人們之是以要靈活，是因為他們憑直覺知道如果不是的話，那它們就是遺物，但是對他們而言，這樣做必須是安全的。”
紮克同意。他說：“員工需要知道管理層會'放手'并允許他們進行自我管理。” “他們還需要看到他們可以小失敗而不受到懲罰。”
障礙
7.忽略客戶回報
客戶回報是靈活傳遞過程不可或缺的一部分。Wolanow說：“靈活學科和傳統傳遞方法之間的主要差別之一是，靈活計劃希望整個項目中都能獲得回報，而不僅僅是在授權的控制門上。”
客戶回報對于確定任何靈活團隊的建設将是有用的至關重要。“在沒有客戶回報的情況下，要優先确定要關注的領域非常困難，團隊最終可能會把所有事情都視為重要，這與什麼都沒有一樣重要，”阿齊茲說。
埃利奧特說：“靈活使客戶融入了流程，這是流程起作用的關鍵。” “使客戶參與計劃和開發的各個方面，您赢得市場的可能性将成倍增長。”
要記住的另一個重要點是，靈活團隊在疊代結束時進行回顧時将使用并依靠客戶回報。紮克說：“在回顧中，團隊分析了在增加建造量方面取得了哪些進展以及哪些方面可以改進。” “然後在下一個建構周期中實作對内部流程的更改。”