最近很忙，有個把月沒讀過書，沒上過這裡，趁著今天專案結題驗收，上來轉轉。
我常常想，我這裡應該是沒有讀者的吧，我完全把這裡當成是一些我腦子裡記不住，或者感覺「啊，原來是這樣」的東西集合地。因此，看起來雜亂無章。
一晃27歲生日就要到了，裝修已畢，婚期將至，手下的人，也越來越多，最近，總是在思考團隊管理的事情。了解過瀑布開發，也了解了uml，然而，當我完全處於好奇，買了敏捷開發這本書時，寥寥幾頁，發現，啊，原來這就是我要找的管理方法，因為，它很貼近目前我所處公司的實際環境。好了，廢話不多，開始拜讀。
首先，我是乙個什麼都不懂的leader，但我要很快變成乙個靠譜的leader...
我們如何打造企業核心能力，毫無疑問，應該是保證質量前提下的交付率。
那麼，我們必須有適合本土的管理體系，對於組織級的管理體系，有兩種方式：
1.可以從企業自我出發，循序漸進的優化流程。前提是，你必須知道自身的痛處和優化重點。這種方法，先重點總結好反思組織當前的實際業務，專案執行過程中遇到的實際問題，然後根據問題的優先順序，選擇某些方面先優先開始優化，並針對組織在該階段的管理水平，團隊能力，想要達到的目標和結果等，進行有針對性的培訓，輔導，執行和覆盤總結，等後收到了實際效果時，再逐步開始其他方面的優化和改進。這種方式的確能收到一些實際效果，但這種組織「優化」文化的形成，技術管理人才的培養，需要經歷乙個比較漫長的過程，可能遇到的問題是時間週期太長，沒有明顯的效果。
2.以體系和管理工具為中心，拿來主義地進行流程優化，即照搬硬套，用的過程中再逐步完善和優化，以適應組織需要。即先僵化，再固化，最後優化。這種方式，效率高，引進速度快，但可能水土不服，因為在企業自身的業務方向，團隊能力，對於流程規範的理解等條件不成熟的情況系，容易引起員工的牴觸情緒，很難深入推進。這一點，我所在公司就是如此。
敏捷專案管理的原則是：可工作的軟體是衡量專案成果的主要指標，軟體可工作，則必須讓一線員工參與選擇和決策。顯然，員工更喜歡沒有廢文件，沒有各種報告，只有每個sprint交付有用的軟體。
那麼，如何敏捷立項？
其實，立項只是傳統專案管理中的事情，在敏捷中，如何簡化立項？實際上，在敏捷中沒有立項之說，你所關注的，只是以下幾個問題點：
1.為什麼要做？也就是要大家共識立項的目的。一般要研發團隊和測試團隊來問產品經理。這與傳統立項不同點在於，它可以讓研發和測試團隊更加積極，而不像以前一樣，有什麼需求，研發就實現什麼需個求，即使需求有邏輯錯誤。而現在，這種方式，讓大家都有了質疑精神。
2.有沒有更重要的專案？其實是優先順序的問題，產品經理列出的n多的使用者故事，具體優先順序如何排，也要在立項時討論清楚。
3.專案的交付結果是什麼？
4.可執行的軟體質量標準是什麼？這一點必須要在立項前定義清楚。
5.有沒有對需求達成共識？對需求達成共識是必須的，這樣大家可以分頭去準備必須的需求文件，設計文件，測試用例。
6.大家最擔心什麼？
然後，sprint計畫會議是在立項前還是後？
建議在立項後，同時sprint計畫會應該多次討論，針對需求，使用者故事，進行合理的工時估算，如果產品在規定的sprint週期內確實無法完成，則可根據優先順序將某些不重要的使用者故事刪除，待下個版本增加。
最後，就是一些立項後專案的基本規則，比如變更。在sprint週期的三分之一處，盡量朝著使用者體驗更好方向提有用的變更，在1/3~2/3時段，團隊只接受優化類別的需求變更，在後三分之一處，拒絕變更。
然而，對敏捷開發中的很多概念，團隊成員並不熟悉，如sprint如何高效的開會？如何估算？如何讓乙個沒有實施過敏捷開發的團隊，成功實現敏捷開發？這些東西，都是需要培訓的。
關於度量
對於乙個具體的專案，採用敏捷專案管理，可以從專案的任務按時完成率，燃盡圖，缺陷移除率等方向實施度量。但不應該講度量與考核放在一起，否則，您只能看到很好的缺陷率報告，交付率圖等。所以，人為產生的度量不應該用來做考核，而是系統產生的，不輕易干預的資料，拿來考核。
不要迷戀度量工具，也不用每次度量很多指標，或者每次度量相同指標，只要度量的資料與直接業務有關，那麼度量就有意義。
關於覆盤
實際上，覆盤框架如下：
目標覆盤->及格/卓越
時間軸->如果你真的注重專案進度，那麼，應該在覆盤中，根據時間軸，做專案檢查點回顧，是否每個檢查點按時達到，如有偏差，是規劃問題，還是執行問題？
得失分析->關鍵任務完成及背後付出的努力/或者重大失誤及原因。
覆盤結論->可以是報告，也可以是覆盤紀要，重要的是，團隊要有成長和學習。
關於敏捷例會
可以採用展示板和資訊系統的巧妙結合，監視專案進度。
關於配置管理
svn，由專門人員負責管理svn。
關於**走查
技術評審，包括需求評審，設計評審，**走查，測試用例評審等和專案直接結果相關的工程活動評審。管理評審指的是敏捷專案管理的三個儀式：sprint規劃會，每日例會，sprint評審會。與傳統專案管理的專案立項評審，里程碑評審和驗收評審也屬於管理評審。
從評審正式程度上，技術評審分為正式評審，技術審查，**走查。其中，技術審查不用準備，**走查也不用準備，但結果不需要確認，其他方面，都需要計畫，準備，會議，修正，確認。
**走查，主要是對**質量分析和程式設計規則做檢查。分兩種，交叉**審查，**會審，內容包括，**規範，滿足功能，邏輯實現，效能要求，對效能影響的瓶頸給出解決方案，**簡化，可讀性提公升。
關於測試報告
測試報告的目的是讓所有團隊成員都熟悉但當前sprint交付軟體的質量情況，每個開發人員身上有多少個bug沒有解決，以及交付模組的質量情況。團隊內部，不要求做正規和全面，應該為團隊減負，提高溝通效率。所以要問團隊需要什麼的報告，基本情況總結，包含bug移除率，bug人員分布，bug模組分布。
一些基本規則：
1.軟體可用規則：即每乙個交付的功能，如果說可用，就一定可用。
2.目標導向規則：即在指定敏捷規劃時，要指定何為卓越，何為及格，有明確的目標。
3.**提交原則：即必須滿足經過單元測試，且提交後整體**編譯通過。
4.有話好好說原則：每個成員必須清楚需求，互相溝通。
5.文件極簡規則：只寫必須的文件，如需求，關鍵點設計，方便長期維護和更新。
6.精英團隊規則：不要求成員規模很大，但要精練。
關於持續優化
敏捷核心思想，倡導款速迭代和交付、燃盡圖方便你觀察整個專案情況，關於燃盡圖可能出現的7種情況，後期在做詳細整理。
燃盡圖（burn down chart）是在專案完成之前，對需要完成的工作的一種視覺化表示。燃盡圖有乙個y軸（工作）和x軸（時間）。理想情況下，該圖表是乙個向下的曲線，隨著剩餘工作的完成，「燒盡」至零。燃盡圖向專案組成員和
企業主提供工作進展的乙個公共檢視。這個詞常常用於敏捷程式設計。
kane mar將燃盡圖分為以下七種情況：
1、fakey-fakey：表面完美而已。軟體專案過於複雜以致於難以界定直觀的目標。大多數情況下，這種圖來自於充滿了命令與控制的環境，在這種環境下，開放的交流變得難以進行。
2、late-learner：燃盡圖中會有乙個頂峰。通常出現在溝通高效且正在學習
scrum的團隊中。
3、middle-learner：要比late-learner更加成熟。團隊在sprint的中期會探尋出大多數的任務與複雜性。
4、early-learner：開始有乙個頂峰，然後是平緩的衰退。團隊認識到早期探尋的重要性，然後高效工作以實現目標。
5、plateau：團隊在一開始取得了很大的進展，但卻在sprint的後半部分喪失了方向。
6、never-never：燃盡圖在sprint的後期突然開始上揚並且不會再下降。需要盡快找到這些遲來的變化並進行自省。
7、scope-increase：sprint中的工作量突然增加。通常這表明團隊在sprint計畫會議上沒有完全認清工作範圍。
集中規劃，優化交付週期。產品人員盡早的組織研發，測試，敏捷教練一起來集中討論下下個版本的需求。
用wikil來建立過程資產庫，記錄團隊開發經驗，
持續整合，保證每個版本可用，且提交簡答。
度量與流程優化，壓縮研發週期，測試週期等。
關於組織文化
1.組織文化，可包容的，不只是質量文化，效率文化，還有適合發揮公司資源到極致的各種文化。
盡量只去做對專案目標有直接影響的事情，要有優化意識，經常去審視別人的**或者自己的**，將**寫的簡而精，在每個功能完成的時候，都要去考慮哪些**需要優化。即優化，也是一種企業文化。
2.對人才，技術和流程制度的完善，包含政策導向，比如員工的政策鼓勵，人才儲備，成立專案管理訓練營，建立公司的資產庫。
3.任職資格管理體系，專案經理培訓，幹部培訓。
到此，簡單結束，將來細細體會。
敏捷開發一千零一夜
敏捷開發一千零一夜 基本資訊 出版社 電子工業出版社 isbn 9787121208188 出版日期 2013 年8月 開本 16開 頁碼 244 版次 1 1 所屬分類 計算機 軟體工程及軟體方法學 軟體方法 軟體工程 更多關於 敏捷開發一千零一夜 內容簡介 計算機書籍 敏捷開發一千零一夜 以多位...
敏捷開發讀書筆記
1 開始時需求要明確 2 盡早發布可執行的demo，持續進行整合 3 功能粒度要足夠低 4 架構可以隨時進行調整 5 測試驅動開發 6 持續整理 及架構重構 7 持續的速度，任務分解需要細緻 粒度要小，各個模組的任務完成要及時 有效 軟體之美在於它的功能，在於它的內部結構，還在於團隊建立它的過程。對...
《敏捷開發一千另一夜》 讀後感1
相信大家都讀過一千零一夜的故事，接下來，我們來回顧一下這個故事。故事有兩個主角，乙個男主 主動方 乙個女主 被動方 互動的方式是 被動方 講故事，可以故事裡巢狀另乙個故事，故事也可以有多個分支。評價體系是這樣的 a 主動方 接收 某個小故事，被動方 繼續 可以見到明天的太陽 b 主動方不接收，被動方...