但是当敏捷成为超过百人团队，或进行大型项目的主流开发方式时，这些自己临时组织起来的技术团队，或者是在跨团队之间，以及日常管理多个团队，如仅靠白板、电子表格和Wiki 等将难以满足需求。 敏捷在一开始要求最低限度的规划，这使得交付新的、意想不到的功能时很容易偏离方向。 此外，这意味着项目没有限定的终点，因为从来没有一个明确的 “最终的产品”样子。 每天的例会、迭代计划会议、迭代评审会、迭代回顾会议都在对可交付成果质量上进行层层把关，因为在这几个会议中会频繁讨论遇到的问题/解决方案，验收标准，DoD等等。 同时，也会邀请项目干系人参加迭代评审会并对可交付成果验收和反馈，这样团队可以及时予以调整，以确保质量。
自 1999 年發展於華人地區，累計諮詢企業超過 4000 家，學員超過 100 萬，橫跨十大產業領域。 作為管理顧問業的先行者，運用清晰的實務經驗與西方的科學工具，影響無數卓越的企業家。 同時，鼓勵靈活、試錯、即時回應、客戶導向與不斷優化等觀念。 同樣的觀點在Martin Fowler的UML Distilled Third Edition中也有所著墨，Martin認為，UML作為一項工具，可以有三種被使用的方式，一種是草圖，一種是所謂的藍圖，最後一種則是程式語言。 敏捷式開發是近來時常耳聞的一個名詞，我們或多或少對於這個名詞有些微的概念，但是卻又很難具體的描述出一個全面性的觀點來。
由兩位管理顧問/企業講師 張國洋（Joe）與姚詩豪（Bryan）共同創立。 當需求訪談時，為了要討好客戶，也為了整個Team 在客戶端有好的工作atmosphere，對於客戶的要求，多半會做很多溝通，有時就義務性的多給1,2個 Service. 但要求多了，就得把合約拿出來提醒一下、PM 要保持良好的交際手腕—打電話給合約部門或洽談者接洽。 我覺得軟體開發，就好比養一個小孩一樣 (養成遊戲的觀點), 在適當的年齡還是得進入必要的管理流程，如果讓小孩自己順著他的天分成長，少有的天才，才能在18歲大學畢業。
敏捷: 管理者必學：
Scrum是当下使用范围最广的一种敏捷方法，这种开发模式也称为“橄榄球”式方法：团队成员都对产品开发的整个过程保留自己的看法，实现自治。 产品开发方式由线性方法转向集成方法，这种转变刺激团队内部各层次间的交叉学习、交流以及思维发散。 因为敏捷软件开发的核心思想之一就是：通过自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。
如果团队在25人以下，由于规模小信息差不大，流程简单，很多事情拉个会议，使用一般的白板或者是在线文档就能满足需求，这个时候上工具有时候反而会给团队的效率造成阻碍。 敏捷 我们也能看到，近些年敏捷项目管理在国内的热度持续攀升，BAT等诸多一线大厂普遍采用，敏捷项目管理所带来的价值和优点被越来越多的团队发现。 由于敏捷是以增量的方式交付的，所以跟踪进度需要你跨周期地看。 而 “边走边看 “的特性意味着你不能在项目开始时设置很多KPI。
敏捷: 敏捷的优点：
曾任電視節目執行製作、網站企劃、程式設計師、軟體公司研發部副理。 作者簡介：曾任電視節目執行製作、網站企劃、程式設計師、軟體公司研發部副理。 而天真快樂的小孩本身-(程式設計師本身)，重點看的是這個過程能累積什麼樣好的記憶，好氣氛，好情景在自己腦海裡，而後顯現出自己的行為給外在的人做評估，這個部分不用做文件的。 隨便長，也是一個樣，照書養也是一個樣，基本上功能性健全就可以了，至於氣質及完善程度，或有沒有賣相就無所謂了。 其實延伸敏捷式開發的議題，筆者聯想到一個一直在台灣軟體資訊界爭論不休的問題，就是CMMI究竟對臺灣軟體有沒有幫助。 其實敏捷式開發的精神與CMMI這類流程與制度導向的觀點在某些層面是有衝突的，如果制度化一切是個良方，那麼敏捷式開發出現就顯得沒有道理。
我們的初衷是建立一個共享知識平台，將專案管理、產品開發、時間管理與企業經營等知識，用淺顯易懂且容易實踐的方式，分享給大家。 若是透過Focus Group定期取得使用者的回饋也是一種方法，當然這比較花時間，但若是一個新產品上市的產品定位設計，就是一個很好的方法取得代表性使用者的使用經驗。 Product Backlog是該產品所有已知需求的排序表，主要由PO負責。 Product Backlog會不斷變化，找出什麼對產品是最有競爭力、最有用的。 Product Backlog會列出所有特性，功能，需求，改善功能和修補方式，這些會影響未來產品發表的內容。 一旦客戶改變想法，建議靈活變通，以完成新目標為主，而不是用最初的規定。
敏捷: #1.「個人與互動」重於「流程與工具」
邀您一同為深耕專案管理努力，您的參與，相信能為您的產品/服務，擴展商機， 無形中，也為專案經理雜誌的永續經營注入契機。 團隊的後勤人員最好先參加業務會議，了解市場需求，才能即時依數據提供情報，共同規則可以幫助雙方排除溝通障礙，使團隊運作更加順暢。 在敏捷管理中，負責人會把專案切成小分，讓團隊可以先專注在最優先的部分，且每個團隊都要成為對結果負責的「自組織」。 Scrum中主要有9個活動類型，主要的目的是創造專案開發的規律性，與避免不必要的會議產生，我們一項一項來看。 PO是決定產品要做成什麼樣子的人，需要決定產品的規劃並為產品的成敗負責，不僅要具備敏銳的市場sense，還要擁有優良的溝通力，好應對利害關係人。 敏捷从国外传入国内，由于滋生土壤不一样，必然有一个适应完善的过程，逐渐发展出适合国内环境的敏捷项目管理模式。
當然，既然稱作一種原則，就代表團隊引用敏捷式開發時，並非照本宣科的一股腦引用，而是應該審視團隊與公司的文化及產業特性，來評估能夠參考的部份。 換句話說，它希望開發者使用塑模的時機，是當使用這個技術有助於開發者更了解被開發的軟體時才使用，例如某些具關鍵性的議題或者高風險性的項目，而非不管三七二十一的將軟體所有範圍的設計都加以塑模留下文件。 在敏捷式開發中有個很重要的觀點是筆者很感興趣的，它認為塑模（Modeling）的目的在於增加開發者了解軟體的程度，進而使得軟體更接近於使用者的需求，而非使用塑模之後產生的文件。 Daily Scrum是針對開發團隊的一項活動，會在Sprint開始之後每天招開，時間應控制在15分鐘左右，主要的目標是檢視進度，Daily Scrum討論主題主要有「昨天做了什麼」、「今天打算做甚麼」、「是否遭遇阻礙與困難」這三類。
敏捷: 敏捷是一種價值觀和原則
不管是專案管理還是開發軟件，這類知識型項目是動態的，外界的需求變化速度快，相應技術的進步也相當迅速。 以開發軟體來說，如果空有詳盡的文件，卻沒有在過程中持續產出可用的軟體或功能，最後的產品可能就不符合客戶的需求，因此與其重視非常詳盡的文件，不如持續產出可用的功能。 藉由快速試錯來蒐集第一手情報，反饋後凝聚團隊修正方向，重新開發更貼近客戶需求的商品或行銷策略，敏捷並非只重視專案執行的速度，更要求專案的精準性與即時性，才能因應現今變化快速又詭譎的市場。 「為什麼每天認真地按照工作計畫，結果卻不如預期？」或許這並非是你管理的方式錯誤，而是你需要換一個管理思維。 敏捷基于价值驱动，它的项目范围是可以灵活调整的，这就给项目干系人很多的灵活性来根据市场不断调整需求范围、变更以及优先级等等。
- 以開發軟體來說，如果空有詳盡的文件，卻沒有在過程中持續產出可用的軟體或功能，最後的產品可能就不符合客戶的需求，因此與其重視非常詳盡的文件，不如持續產出可用的功能。
- 由于敏捷团队不是一开始就知道产品“最终的样子”，而是在过程中探索用户的需求逐渐知道产品真正的终局状态，这样一来就给前期的规划（成本，时间，资源）带来了很大的挑战（项目越大越复杂这一点变动更加明细）。
- Scrum 框架中包含了 Scrum Teams 和他們相關的角色，活動，產出物，和規則。
- Martin本身則是將作為一種草圖的工具來使用，當然也有人將其作為藍圖來使用。
Sprint的時間長度在整個專案執行的過程中都是固定的（例如一個月），前一個Sprint結束，下一個Sprint就立刻開始。 Sprint的時間不宜過長，否則複雜性與風險均可能提高，因此建議將時間設為一個月或更短。 SM是最資深，最了解敏捷式管理法流程的人，主要的任務就是排除一切是個如同僕人般的領導者，既不具備人事權，也沒有財物權，更不能決定產品走向，並且需要具備異於常人的信心與耐心，輔導團隊了解並推動敏捷管理。 面對專案執行過程中的變化，或預見即將出現的問題時，需要與客戶重新定義合同，雙方達成一致之，專案才能順利執行下去，做出真正符合客戶的成品。 重視文件的細節固然也很重要，但是別忘了，開發軟體的初衷就是完成可以流暢作業的軟體；專案也是如此，如果因為過度關注文件而犧牲了開發出可使用的軟件，那麼文件再好再完整，意義也不大。 流程與工具並非不重要，流程與工具是專案執行中應遵循的邏輯與可使用的資源，只是遵循流程和運用資源最終還是回到人的層面，因此才說個人間的互動是專案成功的關鍵，如果空有流程、工具，卻不重視溝通，專案一樣做不好。
敏捷: 敏捷式專案管理與傳統管理的差別
敏捷的議題這幾年來快速地興起，然而敏捷這觀念及方法不只是應用在軟體開發上，我們上期也提到了許多敏捷的跨界應用，如目前熱門的精實創業（Lean Start-up）、或上一期介紹的敏捷行銷（Agile Marketing）。 雖然敏捷的好處很多，但若是你打算將敏捷開發的好處推廣給你的團隊、甚至完全沒聽過敏捷且非軟體背景的高階管理者，該如何做會比較有效呢？ 敏捷提倡不断调整和优化，并在每个迭代的迭代回顾会议进行分析、讨论、总结敏捷当前迭代开发过程中需要改进或者要提升的地方，进而在下个迭代中改进、调整和优化。 这是整个团队成员不断学习，不断提升自己经验、技能的一个很好的机会。 另外，因为敏捷强调客户参与的重要性，对于客户的反馈意见和建议，开发团队也会及时给与相应以及反馈，让双方可以更好的合作，建立更加信任的合作关系。
- 作為管理顧問業的先行者，運用清晰的實務經驗與西方的科學工具，影響無數卓越的企業家。
- SM是最資深，最了解敏捷式管理法流程的人，主要的任務就是排除一切是個如同僕人般的領導者，既不具備人事權，也沒有財物權，更不能決定產品走向，並且需要具備異於常人的信心與耐心，輔導團隊了解並推動敏捷管理。
- 但是反過來思考，制度化的開發也使得印度內的軟體公司不斷壯大，他們很顯然的不會是使用敏捷式開發來運作。
- 「做了對使用者、開發團隊都沒有參考價值的文件或報表，只有你自己看再也沒有人看」。
- 取消Sprint非常消耗資源，因啟動新的 Sprint Planning 要重新集結隊員與分配工作等，這會對 Scrum Team造成重大傷害與消耗，正常情況不應該頻繁發生。
另外像微軟 User Voice 網站，會了解使用者最想要的功能，並開放給使用者來投票，票選最想要的功能，身為PM或是產品團隊成員會依據使用者回饋、優先順序及目前資源狀況，來決定下一個改版。 取得使用者回饋的方式很多種，以微軟的Visual Studio產品為例，我們在線上blog及使用者論壇（forum） 會收到許多使用者的使用問題，這類的問題收集會是一個很好的改版參考。 敏捷管理的這套流程又稱為「scrum」，強調快速產出、取得回饋與修正，可因應市場變化及時修正。 改善了傳統管理法要到最後才看到成果的缺點，有多少資源和時間，就做多少東西。
「Scrum」10分鐘輕鬆搞懂科技巨頭都在用的工作管理術如果公司的組織龐大，你想要更進一步了解如何推動敏捷開發，可以參考這篇《組織太龐大，「敏捷開發」跑得起來嗎？資深 PM 傳授超實用的敏捷心法》裡面有非常實用的資訊。 想推動管理，得從主管做起，主管高層首先要接受新的管理方式並調整思維，讓敏捷成為公司的文化並融入其中，改掉權力一把抓的缺點，讓團隊可以自主，如此才能脫胎換骨。 Increment是指在Sprint 期間內完成的工作項目。 Increment的定義是指這些工作項目中PO與開發團隊一起驗證的部分，簡單的說就是 PO 說要上線就可以馬上上線的東西才算數。
敏捷是项目管理和软件开发的一种迭代方法，可帮助团队更快地向客户，交付价，减少麻烦。 敏捷团队不是把所有事情都押在“大爆炸”的发布上，而是以小的但可消耗的增量交付工作。 需求、计划和结果会得到持续评估，因此团队拥有快速响应变化的机制。
如果因为市场、技术或者其它原因失败了，可以及时停止该项目，降低项目风险。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用，並且必須註明原文標題、連結、及作者訊息。 您正在瀏覽的是 Project 敏捷 Up （專案管理生活思維）網站。
敏捷: 敏捷是什麼？敏捷的價值觀
2001年2月，Martin Fowler，Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。 在这次会议上面，他们正式提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。 除了價值觀之外，還有 12 項敏捷宣言原則，這些原則不告訴你具體怎麼做，而是讓你可以在特定情況下做出正確的決策。 我從 Programmer 晉升到專案經理後，在回頭看看這個過程，才發現當眼界變大變廣的時候，思考角度又不同了。 團隊應由小至大：先由小團隊先試水溫，願意學習跟分享，再逐步推廣，同時團隊成員也要沉得住氣，一開始跌跌撞撞沒關係，但至少一次次進步，培養足夠的信任基礎後，團隊才能享有更多自主權。
例如，雖然一個團隊可能認為站立會議很有幫助，但之所以有這種開會方式，只是因為團隊遵循了敏捷的原則和價值觀。 當你明白這一點時，就容易看出敏捷實際上是一系列的理念（價值觀）。 在軟體開發／專案工作中，團隊可以用這個理念來更好地做決策。 培養敏捷的思維如何開始，本文僅說明「培養以使用者為中心的思維」，你們可以在公司內部訓練時去練習看看，進而融入在日常工作中，希望本文對你們的專案管理及產品開發工作有所幫助。
Daily Scrum結束後，開發團隊應再次討論詳細內容，重新調整開發步調。 SM則負責監督，確保開發團隊每天都有做Daily Scrum並且都在時間內完成。 在Sprint Planning 期間，開發團隊就應該先預測好本次能完成的進度，如果開發團隊發現任務太多或太少，可和PO重新討論。 Sprint Planning結束後，開發團隊應準備好並向SM與PO說明預計怎麼分工來完成任務。 Scrum 最初是一個被用來管理「生產錯綜複雜產品」的框架，運用 Scrum 可以清楚的呈現不同產品管理方法和工作技巧的功效，因此你可以持續改善產品，團隊，還有工作環境。
由上述例子你可以發現，多問為什麼，才能幫助你找到root cause，得到真正的insight，而不是表面的現象，這才有助於你後續的改善。 取消Sprint非常消耗資源，因啟動新的 Sprint Planning 要重新集結隊員與分配工作等，這會對 Scrum Team造成重大傷害與消耗，正常情況不應該頻繁發生。 敏捷 敏捷 敏捷 20世纪50年代-美国国防部（DOD）和美国航空航天局（NASA）开始采用迭代式的增量方法（IID）。
在介紹專案鐵三角的時候我們可以了解，專案是以範圍、成本、時間展開的，而傳統管理（經典管理）的特色是先將範圍確定後，再分配人力與時間，並且在專案執行的過程隨時追蹤與掌控。 開發團隊可在Daily Scrum中追蹤剩餘工作量，除了可以以預測達成本次Sprint目標的可能性，也可以管理本身的進度。 開發團隊預測本次Sprint能完成的進度，而「產品目標」與「達成目標必須完成哪些Product Backlog items」則是由PO決定。 顧名思義就是指擁有獨立完成專案能力的團隊，人數5-9人為佳。 是決定該如何完成專案的人，具備自我管理和持續改善的能力。 敏捷式管理又稱為「Agile」，藉由快速試錯來蒐集第一手情報，反饋後凝聚團隊修正方向，重新開發更貼近客戶需求的商品或行銷策略。
傳統專案管理法有個別稱叫「瀑布式管理法」，顧名思義，專案執行的流程就如同瀑布般由上而下發展，一開始的需求就非常明確，不過前置作業與規劃很花時間，等規劃都好了才會開始執行，一旦中間發生變化，先前的規畫都得打掉重來。 敏捷 Sprint Backlog是開發團隊期望在本次Sprint中包含哪些功能，以及提供如何完成此目標的計畫。 如果出現了新的工作，開發團隊會將其加入Sprint Backlog，隨著工作的進行，團隊應重新評估剩餘的工作，如果該部分被認定為不需要，這部分就會被移除。 Sprint目標是開發團隊與PO之間協商的結果，Sprint目標應該具體且可衡量，通常通過一組特定的產品功能項目進行詳細說明，它應該是一個簡短的句子，例如「添加，刪除和更新購物車的數量」、「開發結賬流程：支付訂單，挑選運費，訂購禮品包裝」。
SEO服務由 featured.com.hk 提供
