記錄一下敏捷開發的一些過程，因為沒有實實在在的走這個流程，新公司會按這個模式開發，自己也很有興趣，因為之前也帶了一年多專案，也曾深陷泥淖，所以很期待這個模式下的開發實踐帶來的效果。
在迭代計畫會上，產品負責人講解迭代要開發的條目，團隊進行估算並放入下乙個迭代。（在這產品負責人建立條目化的產品待開發項，並進行優先順序排序。）
實際的實踐上是花了兩天的兩個會議來完成的。
day 1 《專案迭代需求分析會議》
實錄：開會時間是在下班前乙個小時展開的，所以會議節奏比較快。流程如下： 1. pm花了大概5分鐘給大家陳述了scrum的乙個開發流程，因為是新團隊，有些小夥伴對這個理解不多。 2. po花了10分鐘左右給大家講述了第乙個迭代的需求。 3. 提問環節。pm開啟了如下的乙個**檔案,裡面記錄了一些故事點和不明確的點，就這些點還有大家其他的一些問題進行提問，po回答問題明確需求。
day 2 《故事拆分&&時間評估會議》
實錄：上午9:15開展的會議。流程如下：
1. pm針把昨天列出來的故事寫在小卡片上，然後讓開發自己針對故事點拆分需求點，也寫在卡片紙上，然後貼在強上。大致效果如下圖：
如此以來所有的故事點的需求就拆分好了。
2. 時間評估。時間評估主要存在兩個方面的問題：
a. 開發人員水平不一樣，估出來的時間差距比較大;
b. 不同的人對需求的理解度不一樣.可能有人理解的過於複雜，有人理解的過於簡單，導致估計的時間差距較大。
pm採取的辦法是紙牌估算法，給每個開發人員幾張牌，不同的牌代表不同的時間單位，如0.5天，1天。針對每個需求點團隊成員考慮幾秒鐘出牌，pm針對團隊成員估算的時間折衷確定乙個時間。如果出現時間差距特別大的情況，那麼應該是是如上所描述的情況導致，這時候就讓這兩個開發人員說一下自己的理解。這個時候可以幫助大家進一步明確需求。
敏捷開發（一）敏捷開發和Scrum
工作的軟體是首要 進度度量標準。敏捷過程 提倡可持續的開發速度。責任人 開發者和使用者應該能夠保持乙個長期的 恆定的開發速度。不斷地關注 優秀的技能和好的設計會增強敏捷能力 簡單 盡最大可能減少不必要的工作 是根本的。最好的構架 需求和設計出自與 自組織的團隊。每隔一定時間，團隊會在如何才能更有效地...
敏捷開發一
敏捷開發 agile development 概念從2004年初開始廣為流行。bailar非常支援這一理論，他採取了 敏捷方式 組建團隊 capital one的 敏捷團隊 包括3名業務人員 兩名操作人員和5 7名it人員，其中包括1個業務資訊指導 實際上是業務部門和it部門之間的 翻譯者 另外，還...
敏捷開發分享 一
三 敏捷與傳統 什麼是專案?事先規劃好的工作計畫,需要在定義好的時間 工作量和計畫下去完成。專案有其目的和目標，並 且經常必須在限定的時間和預算內完成 什麼是專案管理?用於完成乙個專案的過程。什麼是專案管理?用於完成乙個專案的過程。什麼是敏捷專案管理?這種專案管理的風格專注於商業價值的盡早交付 專案...