敏捷5大優勢

而敏捷能够帮助团队在小步快跑的过程中能够快速的响应变化。 等到 project lifecycle from initiate transfer to design. PM 要花很多時間從頭講起，若直接切入重點，會有很多回應說應該如何做，其實都是之前與客戶討論過的，只不過是在沙盤推演的時候，因為執行性的不合適被否決，有些是起因於標準，或是已經的policy. 在Craig Larman的Applying UML and Patterns第三版（該書的第二版著重在UP開發流程的說明，在第三版中才加進了敏捷式開發的精神）中花了不少篇幅在闡述敏捷式開發的一些定義。

敏捷式開發並非一種制式的開發方法，而是一種軟體開發的精神（spirit），任何開發方法都可以加入敏捷式開發的一些原則進而改善軟體開發的成效。 另外像微軟 User Voice 網站，會了解使用者最想要的功能，並開放給使用者來投票，票選最想要的功能，身為PM或是產品團隊成員會依據使用者回饋、優先順序及目前資源狀況，來決定下一個改版。 取得使用者回饋的方式很多種，以微軟的Visual Studio產品為例，我們在線上blog及使用者論壇（forum） 會收到許多使用者的使用問題，這類的問題收集會是一個很好的改版參考。 敏捷管理的這套流程又稱為「scrum」，強調快速產出、取得回饋與修正，可因應市場變化及時修正。 改善了傳統管理法要到最後才看到成果的缺點，有多少資源和時間，就做多少東西。 傳統專案管理法有個別稱叫「瀑布式管理法」，顧名思義，專案執行的流程就如同瀑布般由上而下發展，一開始的需求就非常明確，不過前置作業與規劃很花時間，等規劃都好了才會開始執行，一旦中間發生變化，先前的規畫都得打掉重來。

敏捷: 敏捷的起源

在介紹專案鐵三角的時候我們可以了解，專案是以範圍、成本、時間展開的，而傳統管理（經典管理）的特色是先將範圍確定後，再分配人力與時間，並且在專案執行的過程隨時追蹤與掌控。 開發團隊可在Daily Scrum中追蹤剩餘工作量，除了可以以預測達成本次Sprint目標的可能性，也可以管理本身的進度。 開發團隊預測本次Sprint能完成的進度，而「產品目標」與「達成目標必須完成哪些Product Backlog items」則是由PO決定。

• Sprint目標是開發團隊與PO之間協商的結果，Sprint目標應該具體且可衡量，通常通過一組特定的產品功能項目進行詳細說明，它應該是一個簡短的句子，例如「添加，刪除和更新購物車的數量」、「開發結賬流程：支付訂單，挑選運費，訂購禮品包裝」。
• 宣言明確指出，敏捷不是一種方法論，也不是開發軟體的方法，更不是一個規則或過程。
• 但是当敏捷成为超过百人团队，或进行大型项目的主流开发方式时，这些自己临时组织起来的技术团队，或者是在跨团队之间，以及日常管理多个团队，如仅靠白板、电子表格和Wiki 等将难以满足需求。
• 敏捷在一开始要求最低限度的规划，这使得交付新的、意想不到的功能时很容易偏离方向。

也就是說，用以在團隊開發時討論以及研究議題的一種工具，在過程中利用塑模的技術來讓問題得到解決，一開始的動機並非為了留下設計圖讓程式設計師去實作。 原則上敏捷式開發主要的精神在於較短的開發循環（建立在反覆式開發方式上）以及漸進式開發與交付。 換句話來說，專案的成果，包含計畫、各類的需求細節、設計等都會隨著專案的進行而漸漸完整，而非在一開始將所有的計畫與需求擬定完成。

敏捷: 敏捷是一種價值觀和原則

團隊中的PO、SM這兩個類似於舵手的角色，若也能清楚、明確的指引團隊方向，確保在做正確的事情。 同時也需要讓團隊有獨立開發的空間，團隊願意接受敏捷管理的意願也會越高。 敏捷式管理法則是先固定成本與時間，在專案執行的過程不斷的深入、細化範圍，以便在有限的時間提交出另顧客、市場滿意的作品。

Sprint是Scrum的核心，可以理解為「衝刺期」，目的是為了在這段時間完成可用或可測試的產品。 Sprint的時間長度在整個專案執行的過程中都是固定的（例如一個月），前一個Sprint結束，下一個Sprint就立刻開始。 Sprint的時間不宜過長，否則複雜性與風險均可能提高，因此建議將時間設為一個月或更短。 SM是最資深，最了解敏捷式管理法流程的人，主要的任務就是排除一切是個如同僕人般的領導者，既不具備人事權，也沒有財物權，更不能決定產品走向，並且需要具備異於常人的信心與耐心，輔導團隊了解並推動敏捷管理。 面對專案執行過程中的變化，或預見即將出現的問題時，需要與客戶重新定義合同，雙方達成一致之，專案才能順利執行下去，做出真正符合客戶的成品。 重視文件的細節固然也很重要，但是別忘了，開發軟體的初衷就是完成可以流暢作業的軟體；專案也是如此，如果因為過度關注文件而犧牲了開發出可使用的軟件，那麼文件再好再完整，意義也不大。

敏捷: #1.「個人與互動」重於「流程與工具」

「Scrum」10分鐘輕鬆搞懂科技巨頭都在用的工作管理術如果公司的組織龐大，你想要更進一步了解如何推動敏捷開發，可以參考這篇《組織太龐大，「敏捷開發」跑得起來嗎？資深 PM 傳授超實用的敏捷心法》裡面有非常實用的資訊。 想推動管理，得從主管做起，主管高層首先要接受新的管理方式並調整思維，讓敏捷成為公司的文化並融入其中，改掉權力一把抓的缺點，讓團隊可以自主，如此才能脫胎換骨。 Increment是指在Sprint 期間內完成的工作項目。 Increment的定義是指這些工作項目中PO與開發團隊一起驗證的部分，簡單的說就是 PO 說要上線就可以馬上上線的東西才算數。 Daily Scrum結束後，開發團隊應再次討論詳細內容，重新調整開發步調。 SM則負責監督，確保開發團隊每天都有做Daily Scrum並且都在時間內完成。

另外，敏捷提倡频率与团队和客户沟通交流，并不断根据反馈和意见调整管理方法、需求流程、开发流程以及运维流程等等。 圍繞著敏捷的大部分討論都與以下事情有關，各種理論方法，甚至特定的開發軟體，儘管這些事情可能會協助團隊建立敏捷，但這些方法和工具本身並非完全是敏捷。 如果你問矯正鞋的廠商，你會了解敏捷的關鍵是開會的時候每個人都要站起來（實現站立會議）。

敏捷: 敏捷式專案管理與傳統管理的差別

另外，因为敏捷强调客户参与的重要性，对于客户的反馈意见和建议，开发团队也会及时给与相应以及反馈，让双方可以更好的合作，建立更加信任的合作关系。 我們的初衷是建立一個共享知識平台，將專案管理、產品開發、時間管理與企業經營等知識，用淺顯易懂且容易實踐的方式，分享給大家。 若是透過Focus Group定期取得使用者的回饋也是一種方法，當然這比較花時間，但若是一個新產品上市的產品定位設計，就是一個很好的方法取得代表性使用者的使用經驗。

除了價值觀之外，還有 12 項敏捷宣言原則，這些原則不告訴你具體怎麼做，而是讓你可以在特定情況下做出正確的決策。 我從 Programmer 晉升到專案經理後，在回頭看看這個過程，才發現當眼界變大變廣的時候，思考角度又不同了。 團隊應由小至大：先由小團隊先試水溫，願意學習跟分享，再逐步推廣，同時團隊成員也要沉得住氣，一開始跌跌撞撞沒關係，但至少一次次進步，培養足夠的信任基礎後，團隊才能享有更多自主權。 要讓員工接受新的管理方式，管理者可藉由薪資、考績等誘因推廣，同時灌輸敏捷管理的觀念，才能在轉型期間避免人才流失。 Sprint被取消之後，需檢視這段期間已經完成的項目，PO會接受那些屬於潛在可發布類型的項目，並且重新審視未來是否要繼續花時間完成那些項目。

敏捷: 敏捷式專案管理是什麼？3分鐘快速了解【2021最新版】

PO應於每次的Sprint Reviews裡追蹤剩餘的工作量，並與之前做比較，評估預期的工作進度與是否能如期完成，而這些資料都必須對利害關係人公開。 敏捷 敏捷宣言發布之後，又再細分出十二項敏捷原則，目的是為了幫助和指導團隊有更詳細的原則，好度過轉型過程的陣痛期。 敏捷 如果团队在25人以下，由于规模小信息差不大，流程简单，很多事情拉个会议，使用一般的白板或者是在线文档就能满足需求，这个时候上工具有时候反而会给团队的效率造成阻碍。 我们也能看到，近些年敏捷项目管理在国内的热度持续攀升，BAT等诸多一线大厂普遍采用，敏捷项目管理所带来的价值和优点被越来越多的团队发现。 由于敏捷是以增量的方式交付的，所以跟踪进度需要你跨周期地看。

取消Sprint非常消耗資源，因啟動新的 Sprint Planning 要重新集結隊員與分配工作等，這會對 Scrum Team造成重大傷害與消耗，正常情況不應該頻繁發生。 敏捷 20世纪50年代-美国国防部（DOD）和美国航空航天局（NASA）开始采用迭代式的增量方法（IID）。

敏捷: 敏捷的优点：

例如，雖然一個團隊可能認為站立會議很有幫助，但之所以有這種開會方式，只是因為團隊遵循了敏捷的原則和價值觀。 當你明白這一點時，就容易看出敏捷實際上是一系列的理念（價值觀）。 在軟體開發／專案工作中，團隊可以用這個理念來更好地做決策。 培養敏捷的思維如何開始，本文僅說明「培養以使用者為中心的思維」，你們可以在公司內部訓練時去練習看看，進而融入在日常工作中，希望本文對你們的專案管理及產品開發工作有所幫助。 敏捷的議題這幾年來快速地興起，然而敏捷這觀念及方法不只是應用在軟體開發上，我們上期也提到了許多敏捷的跨界應用，如目前熱門的精實創業（Lean Start-up）、或上一期介紹的敏捷行銷（Agile Marketing）。

Scrum 框架中包含了 Scrum Teams 和他們相關的角色，活動，產出物，和規則。 每個框架中的組成都有特定的目的，也都是讓 Scrum 成功和運行的必要條件。 Scrum 規則把角色，活動和產出物整合在一起，也主宰了各個組成之間的關係和互動。 自2001年的敏捷宣言提出以来，以极限编程为首的一系列敏捷方法逐渐走入大众视野，在随后的发展中，各类敏捷方法都有所偏向，逐渐形成各自的特点及原则。 尽管敏捷带来了很多改善，但是再次重申它并不是适合所有人和所有情况的。

敏捷: #3.「客戶的合作」重於「合約協商」

在Sprint Planning 期間，開發團隊就應該先預測好本次能完成的進度，如果開發團隊發現任務太多或太少，可和PO重新討論。 Sprint Planning結束後，開發團隊應準備好並向SM與PO說明預計怎麼分工來完成任務。 Scrum 最初是一個被用來管理「生產錯綜複雜產品」的框架，運用 Scrum 可以清楚的呈現不同產品管理方法和工作技巧的功效，因此你可以持續改善產品，團隊，還有工作環境。 敏捷式管理又稱為「Agile」，源自於軟體開發，其核心理念為「快速試錯、即時回應、顧客導向、排定優先順序分配資源」 。

SEO服務由 Featured 提供