親愛的老師您好 感謝您選用本書作為授課教材，博碩文化準備本書精選簡報檔，特別摘錄重點提供給您授課專用。 說明： 博碩文化： 1、本教具為非賣品，不得作為商業之用。 2、本教具僅授權使用原著作為授課教材之教師作為教學或研究等學術用途。 3、本教具未授權提供學生任何拷貝、影印、引用、翻印等行為。 4、教師若需申請網站或內容授權，可透過您的博碩業務協助處理，謝謝。 博碩文化： 總公司：台北縣汐止市新台五路一段112號10樓A棟 電話：(02) 2696-2869 分機 313 傳真：(02) 2696-2867 網址：www.drmaster.com.tw 客服信箱：school@drmaster.com.tw 出書提案信箱 schoolbook@drmaster.com.tw
專案管理 請老師填入姓名主講 課本： 學會專案管理的12堂課 博碩文化出版發行
第十二章 敏捷式專案管理 課前指引 傳統瀑布式專案管理有其限制，無法滿足所有專案的需求；近年來敏捷式的專案管理手法正好彌補了這個缺口，本章對此管理模式做了簡單的介紹。
章節大綱 12-1 敏捷式的起源 12-3 敏捷式專案管理環境 12-2 敏捷式的精神 12-4 敏捷式的迷思
敏捷式(Agile)的概念可以往前追溯到50年代，企圖想要解決軟體開發專案長久以來在傳統的專案管理模式下，所遭遇到的種種無法克服的問題，如： 敏捷式概念的起源 敏捷式(Agile)的概念可以往前追溯到50年代，企圖想要解決軟體開發專案長久以來在傳統的專案管理模式下，所遭遇到的種種無法克服的問題，如： 使用者對於需求的描述很難說得清楚完整 使用者在開發過程中的參與度不夠 軟體需求只能以文字方式陳述 開發團隊耗費太多時間在製作各式文件上
瀑布式開發模式
敏捷式開發模式 反覆 iterative 漸進incremental
敏捷式宣言 2001年2月11日，17位各種漸進式軟體開發方法論的學者專家聚集在美國猶他州雪鳥滑雪渡假村(Snowbird, Utah, USA)共同發表 “敏捷宣言(Agile Manifesto)
十二項原則 經由儘快及持續的產出有價值的軟體，以滿足客戶需求是我們的最大優先考量。 我們歡迎需求變動，即使是發生在開發末期。為了客戶的競爭優勢，敏捷式流程竭盡心力掌握變化。 經常產出可以使用的軟體，週期從數周到數月皆可，但週期越短越好。 業務方面專業人員與開發團隊在專案過程當中，必須要每天在一起工作。 在一群主動且積極的人群中進行專案，提供開發團隊所需的環境，支持並相信他們能夠把事情做好。 開發團隊中採用面對面的溝通對話，是最有效率的訊息傳遞方式。
十二項原則 開發進度的衡量方式，主要看開發出了多少可用的軟體。 敏捷式流程著重持續開發，贊助人、開發團隊、及客戶必須要能維持相同的步調。 持續關注在卓越的技術及優越的設計上，以強化敏捷度。 簡化是必須的 – 所謂簡化是將不需要的工作盡量找出而後刪除。 自我組織的開發團隊會產出最佳的架構、最適當的需求、以及最好的設計成果。 開發團隊會定期自我檢討如何能更有效率，然後調整自己的行為做法。
組織變革 推動敏捷式專案管理是一件組織變革(Organization Change)
敏捷式團隊角色 產品負責人(PO：Product Owner) 團隊主持人(Team Facilitator) 團隊成員(Team Member)
專案預期會產出的交付物件，常以使用者故事(User Story)方式記錄 待辦清單 專案預期會產出的交付物件，常以使用者故事(User Story)方式記錄 做為<某種角色> 我希望<做某件事情> 這樣就可以<得到某些好處>
敏捷開發流程 敏捷式有個特性，就是在一定區間內反覆(iteration)完成專案部分內容，整個開發過程切割成同樣長度的區間
估算工作量 採取相對難度的觀念，例如：故事點(story point) 使用者故事除了要決定優先次序之外，還要從用戶的角度給予故事點代表難度 通常使用費氏數列(Successione di Fibonacci)估算故事難易度
敏捷式迷思 敏捷式不必做計劃 敏捷式不必寫文件 敏捷式比瀑布式好
本章結束 Q&A討論時間