\u0026#xd;\n\u0026#xd;\n
敏捷與創新常被認為存在著緊密聯絡。然而，早前scrum alliance聯合創始人mike cohn批評現在的scrum因太過於關注專案進度，而犧牲了創新能力。他說：
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n在九十年代中期那會兒，scrum講究的是探索創新性方案（這是我作為scrum開發者之一對scrum的回顧）。把問題交給團隊，並給他們乙個月 （或四周）的時間去解決問題。團隊有那麼多時間，便有機會去嘗試一兩種或更多有突破性潛質的方案，而不是直接採用相對保險、經過檢驗的解決方案。
\u0026#xd;\n\u0026#xd;\n
而現在的scrum，團隊變得過分急於宣稱完成任務。這導致團隊傾向於直接採用保險的解決方案。許多團隊絕不會去嘗試瘋狂的、卻可能產生創新方案的念頭。
\u0026#xd;\n\u0026#xd;\n
我覺得這一結果很大程度上跟縮短sprint週期有關——如今sprint通常只有兩周。sprint較短的話，一旦某個有希望但存在風險的方案失敗，就沒有足夠時間來進行彌補了。
\u0026#xd;\n
cohn並不是唯一得出此結論的人。來自英國倫敦城市大學（city university of london）的軟體工程學者bianca hollis和neil maiden教授也認同，短的sprint週期會不利於創新孵化和創新性思維所需要的反思。他們在發表於《ieee software》雜誌上的文章《用創新技術來擴充套件敏捷流程（extending agile processes with creativity techniques）》中 寫到：
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n敏捷流程的乙個明顯不足是：沒有充分利用可工作的軟體來進行新需求的創新性思考。「避免浪費、降低複雜性」這一簡單性原則被過分強調了。例 如，kent back建議敏捷開發者考慮最簡單的方案。儘管這樣做常常十分有效，但除非竭盡全力去嘗試最簡單方案以外的潛在方案，否則，客戶只有勉強接受現有方案，而 不會了解到其他可能。
\u0026#xd;\n
所以，專案效率與團隊創新是時間維度上的不同方向，只能在二者間尋求平衡，敏捷專案不可能同時做好這兩點。
\u0026#xd;\n\u0026#xd;\n
另一方面，在2014 pmi全球大會上有乙個來自pedro serrador的實證研究報告（相關**將在《國際專案管理雜誌（the international journal of project management）》上發表)。該報告顯示，敏捷專案在滿足效率指標（即成本、時間、範圍）上做得較好，而在改善客戶滿意度方面的成功尤為突出。他還發現，許多敏捷專案在先期規劃（即所謂的sprint 0）上花去了跟瀑布專案一樣多的時間。許多敏捷專案正是在這一階段對更廣泛的專案目標與長期需求做了處理。
\u0026#xd;\n\u0026#xd;\n
鑑於客戶滿意是敏捷的首要原則，那麼似乎客戶對於敏捷專案應該更面向創新還是更面向進度有最終發言權。你怎麼看？你在專案效率與團隊創新之間尋求平衡上有何經驗？你們的客戶滿意嗎？
\u0026#xd;\n\u0026#xd;\n
檢視英文原文：
敏捷專案應該面向創新嗎？
敏捷與創新常被認為存在著緊密聯絡。然而，早前scrum alliance聯合創始人mike cohn批評現在的scrum因太過於關注專案進度，而犧牲了創新能力。他說 在九十年代中期那會兒，scrum講究的是探索創新性方案 這是我作為scrum開發者之一對scrum的回顧 把問題交給團隊，並給他們乙個...
為什麼應該面向介面程式設計
介面是一組規則的集合，它規定了實現本介面的類或介面必須擁有的一組規則。體現了自然界 如果你是 則必須能 的理念。其特點是只能定義抽象方法，不可以定義具體的實現方法。舉例 如果你是人就必須能吃飯，而不同的人吃飯的方式有所不同。public inte ce iperson public class ad...
14 敏捷專案管理 可靠的創新筆記
00.這種確定性 以及相信只要他們努力，就可以 產生 正確的結果 很有可能導致失敗而非成功。01.進化本身，即適應生態系統的變化，是實現推進的乙個突發過程。02.重要的是要記住，任何產品 任何組織都不可能在各個領域做到無限的敏捷。03.思維組織如同乙個活的有機體，其中應變是生命力和生存的關鍵。過渡僵...