三 敏捷與傳統
什麼是專案?
事先規劃好的工作計畫,需要在定義好的時間、工作量和計畫下去完成。專案有其目的和目標，並 且經常必須在限定的時間和預算內完成
什麼是專案管理?
用於完成乙個專案的過程。
什麼是專案管理?
用於完成乙個專案的過程。
什麼是敏捷專案管理?
這種專案管理的風格專注於商業價值的盡早交付、專案產品和流程的持續改進、範圍的 靈活性、團隊投入以及能反應客戶需求且經過充分測試的產品交付。
什麼是瀑布?
傳統的專案管理模式。瀑布依賴於在不同階段完成的工作，像需求、設計、開發、測試和部署。 在瀑布專案中，知道你已經完成了前面乙個階段才能開始下乙個階段。
什麼是需求?
專案期望的產品特性清單。
什麼是設計?
為建立單個產品特性而設定大綱和計畫的階段。
什麼是開發?
產品特性建立的階段。。
9. 什麼是測試?
確保產品開發的效能正常執行的階段。
什麼是部署?
專案的最後階段，產品的全部效能達到可以使用的狀態。
敏捷管理中的範圍
專案中包含的一切。
敏捷管理中的估算（動詞）
確定工作量、時間長度、成本或任務的優先順序、需求、發布、甚至整個專案。
敏捷管理中的估算（名詞）
工作量、時間長度、或任務成本、需求、迭代、發布甚至整個專案。
歷史介紹
敏捷技術的萌芽的產生已經有很長一段時間。最早可以回溯至上個世紀30年代沃爾特·休哈特（walter sherwart）在專案質量方面的計畫-執行-學習-行動-（pdsa）方法。
敏捷宣言
2023年，一組軟體和專案的專家聚在一起討論他們專案成功的相通之處。該小組建立了敏捷宣言，乙份對成功的軟體開發所需價值的宣告：
敏捷軟體開發宣言
我們一直在實踐中探尋更好的軟體開發方法，身體力行的同時也在幫助他人。由此，我們建立了如下價值觀：
個體和互動高於流程和工具；
可工作軟體高於詳盡的文件；
客戶合作高於合同談判；
響應變化高於遵循計畫；
也就是說，儘管右項有其價值，但我們更重視左項的價值。
相比傳統專案管理，敏捷方法能夠提供更大的靈活性和更大的穩定性。首先，你要了解敏捷 專案管理如何提供靈活性，然後我們在討論穩定的性。
乙個專案團隊，無論它使用什麼專案管理方法，都要在專案開始之初面臨兩個重大挑戰。
一、專案團隊對產品最終狀態的認知有限；
二、專案團隊無法預知未來；
對產品知識和未來商業需求的有限了解，幾乎注定了專案的變更。
敏捷宣言的第四個核心價值觀是「響應變化高於遵循計畫」。敏捷框架是以靈活性為基礎建立的。
減少非生產性任務
漫長的工昨日=疲勞的開發人員=不必要的漏洞=更多的漏洞修復=延遲發布=實現價值需要更長時間.產品開發是一種需要持續專注的高強度工作。許多開發人員在正常的工作日裡忙於其他型別 的工作任務，因而不能獲得足夠的開發時間來跟上專案進度。從而形成以上的因果鏈。 最大化工作效率的目標是消除加班，開發人員在工作日專注於**開發。為了提高效率，我 們必須減少非生產性的任務和時段。
敏捷過程只包括一些正式會議。這些會議目標應該非常明確，有特定的主題和有限的時間。 在敏捷專案中，當前的專案狀態對整個組織來說都應該是視覺化的。
敏捷團隊應該有高效的溝通方式。敏捷團隊通過面對面的討論，而非傳送電子郵件來解決問題。
專題展示
演示，而非展示。換言之，給客戶演示你的開發成果，而不是單純的描述。
展示軟體是如何滿足需求與達到驗收標準的。換言之，就是在表述：「這是需求。這些是證明已完成特性的驗收標準。這是符合這些標準的特性成果。
避免正式的幻燈片展示和相關工的準備工作。當你演示可工作軟體時，可工作軟體本身就是最好 的展示。
過程文件
文件是專案經理和開發人員們長期以來的負擔。敏捷專案團隊可以使用以下方式來簡化文件
乙個規格不能適合所有專案：你不需要為每個專案建立相同的文件，而應該為特定的專案選擇所 需要的文件
使用非正式的、靈活的文件工具：白板、記事貼、圖表和其它視覺化的工作計畫展示表都是很好 的工具
使用那些簡易且能夠提供足夠資訊的工具來管理專案程序：不要單純的為了報告而去建立特殊的 專案程序報告，敏捷團隊應該使用直觀的工具來更快速的傳達專案狀態。
更高的質量更快的交付
** 短期的迭代開發限制了特性的數量和複雜程度**
持續整合測試在整個專案過程中維護可工作產品產品負責人參與每天的問題解答，並快速地澄清誤解保證開發團隊的工作狀態，減少**漏洞每次衝刺結束後進行評審總結，及時修正優化工作流程提高團隊績效：
提高團隊績效
敏捷專案管理的核心是專案團隊成員的經驗。
相比傳統的專案管理方法，敏捷團隊能夠能夠獲得 更多的支援，可以花更多的時間專注於自己的工作，並致力於持續的過程改進。 使用敏捷過程，可以讓開發團隊把盡可能多的工作時間專注在產品的研發上。每個衝刺回顧討論都會收穫一些可以讓敏捷專案團隊持續改進的方法。
嚴格的專案控制
敏捷過程提供了持續的資訊流：早例會一起規劃工作任務，隨時更新任務狀態。
需求變更影響最小化：每乙個衝刺中，客戶都有機會基於業務需求來更新產品的優先順序。無論優先順序在下乙個衝刺前幾周或者幾分鐘確定，工作量都不會有什麼不同，需求變更幾乎不會增加任何的管理成本和時間，也不會干擾當前的工作。
敏捷方法使得專案終止更容易：在每一次迭代結束時，都可以判斷當前產品特性是否已經足夠，而低優先順序的特性可能永遠不會被開發。
速度更快，失敗成本更低：
更早和更頻繁的檢測故障的機會；
每隔幾周進行評估和採取行動的機會；
失敗成本降低
敏捷開發（一）敏捷開發和Scrum
工作的軟體是首要 進度度量標準。敏捷過程 提倡可持續的開發速度。責任人 開發者和使用者應該能夠保持乙個長期的 恆定的開發速度。不斷地關注 優秀的技能和好的設計會增強敏捷能力 簡單 盡最大可能減少不必要的工作 是根本的。最好的構架 需求和設計出自與 自組織的團隊。每隔一定時間，團隊會在如何才能更有效地...
敏捷開發一
敏捷開發 agile development 概念從2004年初開始廣為流行。bailar非常支援這一理論，他採取了 敏捷方式 組建團隊 capital one的 敏捷團隊 包括3名業務人員 兩名操作人員和5 7名it人員，其中包括1個業務資訊指導 實際上是業務部門和it部門之間的 翻譯者 另外，還...
敏捷開發之產品級經驗分享
如何決定產品路線圖？如何快速驗證核心使用者需求？如何快速反饋，隨需而變？如何為客戶帶來最大價值服務？基於價值驅動的敏捷專案管理，用有限的時間和資源，先把重心放在對客戶價值最大的20 功能上。然後酌情開發剩餘的80 功能 團隊必須信守承諾，且軟體質量為第一原則，否則，破窗理論會告訴你其後果由多嚴重。個...