敏捷開發：咱們這段時間好像是僞敏捷

自覺良好

就在以前幾篇的時候，咱們已經默默開始給小團隊灌輸敏捷知識。

這個團隊很小，產品：應屆生；開發：畢業一年，初級程序員；還有一個有些經驗的我。

咱們負責的項目有開發任務，同時也有很多運維工做。常常會有新需求插入和變動。

咱們效仿一些敏捷形式和方法。有些作得挺好，有些作得不可以長期堅持。

咱們產品列表比較混亂，沒有作整理細化，有一個摞一個。從外面看整個產品是混亂的，看不清將來方向的。

咱們雖然每週都有計劃，從上面能夠看出，咱們沒有遠期目標。由於個人懶惰，沒有從項目上梳理長期的規劃。

自認爲需求頻繁變更，因此不必清晰的長期規劃。也不是說沒有想過，討論過，也達成一致過。可是沒有落實到產品列表中。

你從產品列表中不會看到將來系統的模樣。

應屆生的產品作麼？他一直也是這麼作的，只是有時咱們稍微缺乏了引導就會止步不前，不是積極性問題，是他有時真的沒法下手。

就比如，你剛畢業就讓你負責系統架構同樣，我想剛畢業的我有心想作，可是內心仍是會戰戰兢兢。

冥冥之中的隱患

其實說到底仍是項目管理的問題。我如今隱隱體會到，敏捷是指導原則，實際貫穿主線的仍是項目管理。

因此二者的結合孕育出了不少的優秀的敏捷實踐。

咱們省去了產品列表的規劃，只有零星的周計劃。咱們甚至沒有了項目回顧會議。

咱們起初所認爲的快 —— 其實是省去了各類產品列表的優先級排列：史詩級、主題級、衝刺級，由粗到細的用戶故事的拆分。

咱們雖然將週期調整爲一週一個計劃，來應對頻繁的運維需求的變動。可是咱們也缺乏了項目相關的評審會議、回顧會議。

咱們只管往前跑，冥冥之中感受本身在作無用功，甚至說咱們所作的任務價值意義不大。

致使這種錯覺的，一個是很大程度上是沒有長遠規劃，另外一個是各類評審和關鍵點沒有設卡，還有一個是沒有了回顧和檢討。

因此要遵循項目管理的主要規律和重要的實踐，雖然這些操做時間上付出是有必定的成本，這些付出是值得的。

須要長遠規劃

就比如你們沒有了共同的目標，這個不利於團隊的士氣，不利於項目的發展。

須要付出時間和精力來作這些事情，這個比如是架構，一部成長史。參與其中的成長是很是有成就的。

產品列表：史詩級用戶故事；主題級用戶故事；衝刺級用戶故事。衝刺級別是具體可執行的任務。

好比史詩級別：做爲一個運維人員，我但願有一個後臺能夠方便個人平常運維工做，來提升處理問題的速度更快地相應客戶。

好比主題級別：做爲一個用戶，我想我發起的任務能夠並行調度而不是長時間等待順序排隊，這樣才能很快並陸續收到反饋。

好比衝刺級別：做爲一個運維人員，我在系統中可以擁有在線對帳的權限，這樣利於月中對帳，而不是每次都須要寫郵件給DBA申請導出.

設卡&評審

關於評審，好比 核心模塊的設計評審（思路和技術點）

需求評審

接口協議的設計評審（命名，出入參）

代碼走查評審

測試用例評審

從各類評審中我收穫到的幾個基本的好處是：

一、對於被評審人員，專業技能上是一個肉眼可見的提高。

二、三個臭皮匠頂一個諸葛亮，你們不一樣的智慧的碰撞會發現不少新的坑。

三、是一種態度的輸出

其中幾個經驗是：

一、功夫都在平時準備：好比設計文檔、接口規範設計文檔、測試用例的用例（這個咱們作的還行，也是須要導師多督促，成員可以主動溝通）

二、會前，發佈一個會議大綱。（這個作得也行，這個都會說一下）

好比會議的主要討論主題是什麼？會議的時間是多久？

本身會大約使用多長時間？留給其餘人員的討論時間是多少？

開會只是一個對當前結果的一個討論。

三、會議設定一個主持人

（這個很重要也頗有效果，以前沒有主持人會議常常超時。關鍵是超時還以爲自豪，自豪會議又討論出不少東西，自豪發言很踊躍。）

其實仍是爲了一個開會的效果，能夠找一個資歷高一點的把控會議。避免過分討論。

也就是你們的時間成本和開會的效果儘可能地高效。

四、結束後整理會議紀要（這個執行得算是及格，可是不夠堅持）

其實會議紀要是次要的，主要是對會議討論的結果負責，最好有產出物或者結論。

項目回顧

項目上的回顧，總結過去，計劃將來。

好的很差的都須要說。我的來講也是這樣，好的很差的都須要總結。我的提升了也是項目總體提升的一部分。

再就是計劃一下接下來的工做，明確下一個版本的目標。

加入測試

由於主要提供接口。一開始咱們的都是本身測試，長此以往就沒有讓測試加入。

開始以爲這樣挺好，流程更短。

如今想咱們的3個總結是：

一、咱們其實作得工做並很多，反而多了，由於兼顧了測試的一部分工做

二、任務多了，有可能影響了工期和質量

三、咱們相信咱們，可是咱們仍是不夠專業。就算是接口簡單不須要測試人員介入。

可是須要測試思惟，測試的測試角度思惟常常會給咱們當頭一棒，很受用。

堅持執行，不斷調整

但願我可以堅持執行，不斷反思調整。

根據成員能力和專業程度採用相關的敏捷實踐，不是全部市面上好的都有效。

本身近期看了不少敏捷相關的書籍，最近又看完的這一本，收穫仍是很大的，糾正了不少原來的認知。

好比：全部的用戶故事必須符合6原則（實際上是容許出現史詩級的用戶故事的）

總結

項目管理，甚至說軟件工程須要咱們不斷吸取並反覆琢磨實踐。

本身立一個Flag 立一個願望，但願上述咱們項目中存在的問題可以在上半年有所改善。

可以督促系統的成長和發展。

（喝茶水有點多，睡不着，深夜發個文章催眠一下）