我好像還沒有完全踐行過敏捷開發。不過這段時間一通學習下來，結合以往的一些經歷，認為敏捷的精髓在於多職能團隊和迭代思想。
1、多職能團隊
意味著團隊成員參與了整個專案的絕大部分工作：任務領用、需求分析、設計及開發、測試、評審。
比如，需求分析，以往都是由乙個所謂系統分析員來寫；而在敏捷裡，是由產品經理在計畫會上講故事，然後由各人報所需工時，任務領用，然後進行開發。這裡看上去似乎沒有所謂需求分析，有的話，也是由產品經理整理，但極有可能，產品經理也不寫這個東西，他只是整理了「產品功能列表」，及相關的使用者故事，並沒有乙份所謂的《需求分析》。如果我們需要有這份東西的話，那應該是由大家後來共同撰寫，補上去的。
這樣一來，傳統專案中，系統分析師撰寫需求分析的時候，大家閒著，寫出來後塞給大家，大家也不怎麼看，完全雞肋；而敏捷中，大家都參與其中，一方面，加快了進度。另一方面，由於參與，所以對整個專案都很了解，工作態度也積極主動得多。如果要讓乙個人對一樣東西感興趣，最有效的手段莫過於讓他參與。
全體團隊成員參與計畫會，是敏捷的基礎。
2、迭代
scrum聲稱擁抱變化，但是有前提的，在乙個迭代過程中，拒絕變化。
所謂的迭代，是可以工作的版本。所有模組，在迭代週期內，都必須完成。完成就是完成，不完成就是不完成，所謂完成了99.9%都不算，都不能進入該迭代。在下一輪迭代中重新排計畫。
3、每日立會
似乎每日立會是敏捷開發的標桿性動作？只要我們每天站著開幾分鐘會，就立刻敏捷起來。
其實，據我觀察，每日立會似乎就是乙個匯報會，每個專案組成員都向專案經理（scrum master）進行匯報，主要是匯報昨天做了啥，今天準備做啥，然後專案經理會問一下，有啥困難沒有。
其實，匯報的內容沒有錯，但匯報物件、以及匯報重點搞錯了。立會並不是大家向專案經理匯報，而是向全體專案成員介紹自己的工作，重點在於今天要做什麼，以及遇到了什麼困難，目的是看能不能得到協助，以及避免做重複性的工作。比如自己想做個共用的功能，也許已經有人在做了。
而每日立會的基礎，是全體成員都參加了開發任務的計畫會，所有模組大家都很清楚，因此立會上才互相聽得懂。
4、開發流程
1）產品經理整理需求，列出待開發的產品功能清單，並進行優先順序排序。
優先順序分為重要、緊急、普通等級別。緊急是客戶馬上要的，而重要的是基礎，比如有些緊急的任務的前置條件是重要任務，所以優先級別上，重要》緊急》普通。
2）召開迭代計畫會，產品經理講解使用者故事，專案成員估算，進入迭代任務
3）迭代期限到，完成的功能進入交付版本，未完成的重新進入待開發功能清單；召開評審會、反思會
我有個疑問，這裡面由產品功能清單 -》 迭代任務，如果說需求分析部分是產品功能清單，那概要設計部分在**？整個系統的架構、技術選型這些要在哪個環節進行處理？
敏捷開發學習筆記
敏捷軟體開發是為了防止專案開發中的過程膨脹而提出的。為此，成立了敏捷軟體聯盟，並建立了 敏捷軟體開發宣言 我對敏捷開發的感覺有以下幾點 一 在開發過程中強調人以及人與人之間關係的作用。不但要求開發團隊要有乙個積極向上的氛圍，同時還強調成員與成員之間的合作和交流。例如 每兩名成員組成一對，共同開發乙個...
敏捷開發流程學習筆記
天天在用著敏捷的思想，但是今天面試的時候讓講敏捷，又不知從何說起，今天記錄下 部分內容也有參考網上優秀的易理解的說法。什麼是敏捷開發？敏捷開發 agile development 是一種以人為核心 迭代 循序漸進的開發方法。我理解它僅僅是一種開發方法，更是為了應對激烈競爭和快速 需求變化的一種價值觀...
敏捷開發模式學習筆記
前言 資訊來自網路,沒有原創,只是當成筆記儲存而已 典型的開發模式 流程 調研 開發 測試 驗收 上線 一次 付 缺點 1.研發周期長 2.研發不能很好的相應需求變化 3.風險控制不到位 改善 1.小團隊 2.分析需求與業務同步交流 3.需求池,按照先後順序開發 4.客戶參與研發 1.挑選代表性專案...