rogersnotes 20191226：轉眼間2020年即將到來，Roger老師祝福大家新的一年持續保持競爭力，滿滿戰力補充知識送給你

更多rogersnotes, 請至bk.pm-abc.com.tw........ 訂閱/瀏覽

若您不願意收到rogersnotes，請點按此處進行退訂:http://www.pmsuccess.net/subscriber.asp 或直接回覆本信件通知我們為您處理。

2020 HAPPY NEW YEAR

2019年感謝大家的陪伴，轉眼間，2020年即將到來，

周龍鴻 Roger老師祝福大家在新的一年有新的起點，新的開始。

當代的敏捷式軟體專案管理

一、軟體專案的特性

把軟體專案和其他形式的專案做比較，是否有其獨特的地方？軟體工程界的頂尖大師，軟體專案管理經典著作「人月神話：軟體專案管理之道」一書的作者-Federick P. Brooks, Jr.，指出軟體專案包含了四大獨特性，這些特性使軟體專案和一般專案不同，也因此增加軟體專案管理的困難度。這四大特性分別為：1.軟體的不可見性，2.軟體的複雜性，3.軟體的一致性，4.軟體的易變性。正因為軟體的這些特性，使軟體開發的管理風險相對增加許多。過去幾十年，許多軟體專案管理的業界經驗都告訴我們，正確的應用專案管理手法是軟體專案管理成功的不二法門。

過去幾十年來，世界上許多優秀軟體團隊遵循傳統的軟體開發模式(例如「瀑布式」等)，並成功的結合專案管理手法，順利完成了許多大、中、小型軟體專案，進而使得專案管理、軟體工程(Software Engineering)和系統分析與設計等課程領域，成為成功的軟體開發從業者所必須要有的訓練。儘管成功經驗多，但是，失敗的軟體專案，也是所在多有，軟體專案管理的方法仍不斷演進。

二、現今面臨的挑戰

而現今的經濟環境，更標示著市場快速變化、消費者需求不斷演變的特性。各種產業界中，都不時出現看不見的潛在競爭者，正虎視眈眈，隨時想取代現有的優勢者。因此，軟體專案管理與軟體開發從業人員必須時常保持敏捷(Agile)的特性，也就是在實務上，軟體專案管理者要定義出靈活(maneuverable)、適性(adaptive) 、精實(lean)的各個專案流程(process)，配合PM手法，開發並維護高品質的軟體，以滿足顧客需求，並回應現今競爭的商業趨勢，並且增加自身成功機會和競爭優勢。

三、敏捷(Agile)的起源

「敏捷」是描述開發並上市軟體的一套原則和實務。敏捷這一概念的主要基本精神，其實早已經存在於軟體專案管理界相當長的一段時間。從1950年代以來，美國國防部(DoD)和NASA就已經廣泛使用反復與漸增(iterative and incremental development, IDD)這種彈性的方法開發軟體專案。即使是Dr. Winston Royce 在1970年首度介紹知名的傳統「瀑布式」軟體專案方法的論文中，也用相當篇幅的介紹反覆式手法、與客戶全程參與的重要性，並建議:重視與使用兩者是改善傳統「瀑布式」可能缺失的極可行方法。

1986年，竹內弘高(Takeuchi)和野中裕次郎(Nonaka)發表「New Product Development Game」白皮書，首度提出的以「專注、跨功能性部門、自行組建的團隊(rugby approach)」原則，這正是敏捷式的另一項原則。日後，這本白皮書成為敏捷軟體開發法中，Scrum 法的基礎。

2003年，Mary and Tom Poppendieck 在「Lean Software Development: An Agile Toolkit」一書，強調透過精實(Lean)的持續改進 (持續完善) 、消除浪費，第一次就使品質達到要求，並只產生客戶所要的產品(不鍍金)的重要性。

這些都觀點和貢獻，都影響並促成了現今廣受重視的敏捷方法。

四、軟體開發與管理的新里程碑--敏捷宣言(Agile Software development）

2001年，Kent Beck 等17位軟體專業人士，組成了Agile Alliance(敏捷社群)，並且發表了Manifesto for Agile Software Development(敏捷宣言)，強調軟體專案開發：

- 個人與互動重於流程與工具 (Individuals and interactions over Processes and tools)，

- 可用的軟體重於文件的詳盡 (Working software over Comprehensive documentation)，

- 與客戶的合作重於合約的協商 (Customer collaboration over Contract negotiation)，

- 回應變化重於遵循計劃 (Responding to change over Following a plan)。

宣言中還包括以下原則：

- 及早並持續地交付有價值的軟體以滿足客戶需求。

- 樂於面對改變的需求。

- 經常交付可用的軟體，頻率可以從數週到數個月，以較短時間間隔為佳。

- 專案全程中，業務人員與開發者必須密切的一起合作。

- 專案團隊由積極的個人來組成。

- 面對面的溝通是團隊對外傳遞資訊，及團隊成員之間最佳的溝通方法。

- 專案進度的最重要的衡量標的是可用的軟體。

- 提倡持續的開發，並不斷地維持穩定的步調。

- 持續追求技術的精進與優良的設計。

- 力求精簡，不做不需要的工作 (按：這正符合PM強調得不鍍金觀點)。

- 團隊是自我組建形成的。

- 定期適性調整面對外界永不止息的改變。

新一代軟體開發方法---敏捷軟體開發與管理，自宣言發佈後，引起業界廣泛關注和迴響。相對於「非敏捷」，「敏捷」更強調軟體開發的適性規劃(adaptive planning，如 PMBOK提到的湧浪法即是一例)、演進式發展(evolutionary development) 、跨功能部門(cross-functional)而自我組建型(self-organizing)的團隊、面對面的溝通（比書面的溝通更有效）、早期交付(early delivery) 、持續改進(continuous improvement)的重要，並鼓勵快速且彈性的回應外在不斷發生的改變。

五、業界常見的敏捷式軟體專案管理

新近廣泛被運用的敏捷式軟體專案管理方法包括：

- Scrum: “Scrum”一字，得名來自橄欖球比賽中，競賽球隊的一種動作。Scrum這個敏捷式軟體專案管理方法的主要創建者包括：竹內弘高(Takeuchi)、野中裕次郎(Nonaka)、 Ken Schwaber、與 Jeff Sutherland等。

Scrum是運用反覆(疊代)與增量法(iterative and incremental)的一種敏捷式軟體開發的管理方法。在作法上，Scrum定義了一組軟體流程模式(software process patterns)，而其中每一個個別的software process pattern，都由一組開發活動組成。開發活動的組成成分，包括：

- 專案需求優先序的Backlog，

- 一系列稱為Sprints 的工作單元，

- 團隊對內與對外的日常短期溝通會議--Scrum meetings，和

- 持續產出的軟體交付成果，稱為 Demos。

實務已經證明，運用Scrum法在時程緊迫、需求持續不斷改變、及具企業關鍵性(business criticality)的專案開發上，已獲得相當多顯著的成功實例

- Extreme Programming: Extreme programming (XP)一詞由Kent Beck 所創造。和傳統方法不同的是：這種方法樂於面對開發過程中，客戶不斷提出改變的需求，並經常交付可用的軟體，而藉由新的交付軟體，開發者可以納入客戶不斷變更並增加的需求。此外XP鼓勵溝通、回饋、簡單化、尊重、與勇氣等價值觀，作法上也採取雙人組編寫程式(coding in pairs)以利同儕審查(peer review)，軟體測試也須採單元測試(Unit Testing)的型式。

據調查，XP目前也是最被業界廣泛採用的敏捷式方法之一。

除了上述兩種敏捷式方法外，著名的敏捷式方法還包括歐洲流行的DSDM(Dynamic Systems Development Method)，強調人而非流程的 Crystal Clear Methods、Lean Software Development、Feature Driven Development(FDD)、 Agile Modeling、Agile Unified Process (AUP) 等等。

六、結論

軟體開發與軟體管理一直在尋找萬靈丹，希望有一勞永逸兼顧完美品質、符合時程、不超支成本的軟體開發與管理技術，但是可能正如軟體專案管理大師 Federick P. Brooks 在軟體工程的經典論文「No Silver Bullet — Essence and Accidents of Software Engineering」說的，沒有任何一項技術或方法可使軟體工程的生產力在十年內提高十倍(和硬體的進步程度完全不同)。

PMI的PMBOK指南提供了最優良的專案管理實務的標準。在軟體實務界，不管過去採用傳統的方法(如瀑布式)，或新近的各種敏捷式方法，都應具備結合五大流程、十大知識領域的國際標竿的專案管理架構，才是軟體開發與專案管理得成功王道。

作者：宋泰官, PMP

作者簡介：美國德州大學(UTA)工業工程博士，資訊科學碩士，台大學士，目前任教於南開科技大學資訊管理學系，於2012年8月29日成為PMP。在學校教授網頁設計、專案管理、系統分析與設計等課程，期待未來在教學與研究的工作上，持續軟體與專案管理知識領域的探索與應用。

展望2020年來臨，持續保持競爭力及戰力，已不是一套方法就足夠。

只要三分鐘，讓Roger 老師帶你了解可適用於各行各業的專案管理新趨勢，告訴你企業如何應用「專案管理+敏捷管理」創造競爭力，在現有經營結構下達成敏捷。

Youtube線上學習影片

◎「專案管理+敏捷管理」Hybrid Practice│https://goo.gl/vEoB2v

◎ 鳥的雙翼什麼是Hybrid PM？│https://youtu.be/jq4fRI4JDkE

Agile是專案管理的新趨勢，在現今資訊豐富且市場快速變遷的環境，但企業要突破，不是純的 Agile 或 Waterfall 可以滿足企業營運需求，而是需以混合型專案在現有經營架構下兼融2種專案型態，達成綜效，企業需應用專案管理與敏捷思維在各階層的靈活應用，締造綜效

當專案管理遇上敏捷社團知識平台

結合Hybrid PM 社團所有資源，幫助您更快更好找到敏捷相關資源

成為夠專業GO敏捷的敏捷者

https://sites.google.com/view/hybrid-pm/home-pmabc?authuser=0

加入方式

1. 加入當專案管理遇上敏捷臉書社團:https://www.facebook.com/events/478297499593090/

2. 加入Line 群組（如無法加入，通知LineID:LHCPMP) : http://line.me/ti/g/g5CBxoO_7p

3. 加入專案管理遇上敏捷社員: https://goo.gl/KrhMPy

【敏捷式管理思維培養】敏捷思維是一種好習慣

【敏捷式管理思維培養】敏捷思維是一種好習慣

什麼是「敏捷思維」?

敏捷的議題這幾年來快速地興起，然而敏捷這觀念及方法不只是應用在軟體開發上，我們上期也提到了許多敏捷的跨界應用，如目前熱門的精實創業（Lean Start-up）、或上一期介紹的敏捷行銷（Agile Marketing）。雖然敏捷的好處很多，但若是你打算將敏捷開發的好處推廣給你的團隊、甚至完全沒聽過敏捷且非軟體背景的高階管理者，該如何做會比較有效呢？可先從敏捷思維的建立做起。

「敏捷思維」是一種mindset，一種認知，一種文化，它讓團隊成員對敏捷精神及作法有基本的認識，當團隊成員都有了較一致的想法，自然形成一個團隊文化。我們上次提到了一些敏捷開發的幾個重要精神及原則，本文我想特別說明這一點─「使用者參與並盡早取得回饋」，若能讓公司管理階層及團隊所有成員都能明白了解它的精神，並在每日的工作內容中不斷地提醒自己或團隊成員實踐，定能有事半功倍之效，自然就會培養團隊成員的敏捷思維了。

使用者參與並盡早取得回饋 – 如何培養以使用者為中心的思維

這點是大多數團隊常常忽略的，關在辦公室中「想像」使用者的需求，或是由工程師的觀點，自己認為使用者要什麼，筆者提出幾種團隊可以練習的方法，這些作法很適合在團隊一開始要導入敏捷前，先讓全員都能上的訓練課程，你們可以在公司內部訓練時去演練，再逐步內化到每日的工作中，讓團隊成員能以使用者為中心的思維。

1.邀請真的使用者來說明使用產品的心得，然後多問為什麼

邀請真的使用者來現身說法，類似的作法有focus group，focus group的執行是比較花工夫的，但是在訓練課程時，可以讓使用者來說說使用產品的好及不好的經驗，在詢問時，盡可能多問為什麼，以下舉個例子：

產品經理：「請您自由地說說我們產品哪些地方設計得不好」

使用者會說：「我覺得這產品UI設計的不好用」

請馬上再問：「為什麼你覺得UI不好用？」

使用者回答：「這上面的選單容易按錯」

再追問：「為什麼容易按錯呢？」

使用者回答：「因為選單很密集，很容易按錯」

由上述例子你可以發現，多問為什麼，才能幫助你找到Root cause，得到真正的Insight，而不是表面的現象，這才有助於你後續的改善。

2.試著讓團隊成員輪流當客服

當產品上線或服務正式營運後，若初期能讓產品開發團隊成員輪流排班當客服，包括產品經理甚至 programmer，真實聽聽使用者對於產品的使用經驗，不論是好的，壞的，因為在第一線你會聽到真切的使用者遇到之問題，他們是如何操作你的產品，甚至也可以從對話過程中找出使用者真正的pain point，通常你會意想不到各種五花八門的答案，甚至有些是你們團隊從來沒想過的需求。

在一個大型的企業中，通常客服是由另一個部門來執行，雖然客服也會定期整理report給產品團隊以了解使用者回饋，但在於時效性較難即時，通常產品或服務剛開始營運，初期的使用者聲音是很重要的，再來若是報告的整理是由客服人員的角度所做出來的，可能已經過濾掉許多重要的資訊，你會因此喪失在產品營運初期有機會可以更敏捷地回應及改進，身為敏捷信仰者要不斷從feedback 中精進你的產品。

3.只產出對用戶有價值的東西，減少浪費

「浪費」在敏捷的精神及思維中蠻關鍵的，但浪費這個字眼在軟體開發上不是很容易從字面上理解，在此舉一些浪費的例子及可能的解法（這沒有正確唯一解，視團隊狀況都有所不同）

「那些不能為用戶帶來價值的功能，但你們團隊還是把這個功能放上去了」。可能解法 : 在時間及資源有限的狀況下，先做Priority最高的功能，而不是什麼都做。

「做了對使用者、開發團隊都沒有參考價值的文件或報表，只有你自己看再也沒有人看」。可能解法：只做需要的文件／報表，該文件／報表最好還可以從系統自動動態產生。

「過度計畫 - 一個全新且還沒能很確定用戶需求的產品，身為PM的你還沒執行就花了三個月做一個漂亮的紙上報告」。可能解法 : 先從小計畫開始，有了初步的計畫就可徵得stakeholder的支持，先行透過一個短循環試行你的小計畫，再行修正。

「半製品 – 花了三個月時間做了一個會動的prototyping，才發現沒人要」。可能解法 : prototyping不一定要真的寫出來，也可以是畫出來的UI草圖、一個簡單的動畫可以向使用者說明產品概念。

「一個工程師花了不少時間寫了一個元件，最後發現有現成的API可以用」。可能解法 : 在每日立會時，詢問同仁有無相關的實作經驗，以減少自行摸索時間。

身為敏捷團隊的成員，可透過每日立會時，隨時提醒大家，我們這樣做是不是一種浪費? 有沒有更好的作法? 透過這樣的反覆思考及互相提醒的默契，定能事半功倍並減少浪費。

4.建立可以持續且即時取得使用者回饋的機制

取得使用者回饋的方式很多種，以微軟的Visual Studio產品為例，我們在線上blog及使用者論壇（forum）會收到許多使用者的使用問題，這類的問題收集會是一個很好的改版參考。

另外像微軟 User Voice 網站，會了解使用者最想要的功能，並開放給使用者來投票，票選最想要的功能，身為PM或是產品團隊成員會依據使用者回饋、優先順序及目前資源狀況，來決定下一個改版。

另外一點是，要讓使用者很容易地可以隨時反應問題或回饋，例如：Visual Studio 2013 版本，在使用的過程中有遇到問題，或是建議，可直接在功能選單中用文字的方式回報，也可讓使用者選擇是否自動貼上screenshot讓產品團隊了解使用產品發生問題當下的畫面，這些都是取得 user's feedback 的機制。

若是透過Focus Group定期取得使用者的回饋也是一種方法，當然這比較花時間，但若是一個新產品上市的產品定位設計，就是一個很好的方法取得代表性使用者的使用經驗。

培養敏捷的思維如何開始，本文僅說明「培養以使用者為中心的思維」，你們可以在公司內部訓練時去練習看看，進而融入在日常工作中，希望本文對你們的專案管理及產品開發工作有所幫助。

文章來源：《專案經理》2014年8月號雲朗觀光的專案管理

《專案經理》雜誌歡迎訂閱 https://www.pm-mag.net/index.aspx

＜＜上一則 rogersnotes　　回 rogersnotes 主選單　　下一則 rogersnotes＞＞

rogersnotes 無償分享筆記, 歡迎分享給好朋友. 分享檔案著作權屬 rogersnotes®所有,
欲在公開場合使用rogersnotes® 著作請按此下載使用同意書.roger 連絡Email: PMSuccess@gmail.com
非常滿意　滿意　普通　不滿意　非常不滿意　
退訂或推薦您的朋友共享rogersnotes, 請由此進入