自覺良好

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

這個團隊很小，產品：快一年經驗；開發：畢業一年，初級程式設計師；還有一個有些經驗的我。

我們負責的專案有開發任務，同時也有不少運維工作。經常會有新需求插入和變更。

我們效仿一些敏捷形式和方法。有些做得挺好，有些做得不能夠長期堅持。

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

我們雖然每週都有計劃，從上面可以看出，我們沒有遠期目標。因為我的懶惰，沒有從專案上梳理長期的規劃。

自認為需求頻繁變動，所以沒必要清晰的長期規劃。也不是說沒有想過，討論過，也達成一致過。但是沒有落實到產品列表中。

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

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

就好比，你剛畢業就讓你負責系統架構一樣，我想剛畢業的我有心想做，但是心裡還是會戰戰兢兢。

冥冥之中的隱患

其實說到底還是專案管理的問題。我現在隱隱體會到，敏捷是指導原則，實際貫穿主線的還是專案管理。

所以兩者的結合孕育出了很多的優秀的敏捷實踐。

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

我們起初所認為的快 —— 實際上是省去了各種產品列表的優先順序排列：史詩級、主題級、衝刺級，由粗到細的使用者故事的拆分。

我們雖然將週期調整為一週一個計劃，來應對頻繁的運維需求的變更。但是我們也缺少了專案相關的評審會議、回顧會議。

我們只管往前跑，冥冥之中感覺自己在做無用功，甚至說我們所做的任務價值意義不大。

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

所以要遵循專案管理的主要規律和重要的實踐，雖然這些操作時間上付出是有一定的成本，這些付出是值得的。

需要長遠規劃

就好比大家沒有了共同的目標，這個不利於團隊的士氣，不利於專案的發展。

需要付出時間和精力來做這些事情，這個好比是架構，一部成長史。參與其中的成長是非常有成就的。

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

比如史詩級別：作為一個運維人員，我希望有一個後臺可以方便我的日常運維工作，來提高處理問題的速度更快地相應客戶。

比如主題級別：作為一個使用者，我想我發起的任務可以並行排程而不是長時間等待順序排隊，這樣才能很快並陸續收到反饋。

比如衝刺級別：作為一個運維人員，我在系統中能夠擁有線上對賬的許可權，這樣利於月中對賬，而不是每次都需要寫郵件給DBA申請匯出.

設卡&評審

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

需求評審

介面協議的設計評審（命名，出入參）

程式碼走查評審

測試用例評審

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

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

2、三個臭皮匠頂一個諸葛亮，大家不同的智慧的碰撞會發現很多新的坑。

3、是一種態度的輸出

其中幾個經驗是：

1、功夫都在平時準備：比如設計文件、介面規範設計文件、測試用例的用例（這個我們做的還行，也是需要導師多督促，成員能夠主動溝通）

2、會前，釋出一個會議大綱。（這個做得也行，這個都會說一下）

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

自己會大約使用多長時間？留給其他人員的討論時間是多少？

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

3、會議設定一個主持人

（這個很重要也很有效果，之前沒有主持人會議經常超時。關鍵是超時還覺得自豪，自豪會議又討論出很多東西，自豪發言很踴躍。）

其實還是為了一個開會的效果，可以找一個資歷高一點的把控會議。避免過度討論。

也就是大家的時間成本和開會的效果儘量地高效。

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

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

專案回顧

專案上的回顧，總結過去，計劃未來。

好的不好的都需要說。個人來說也是這樣，好的不好的都需要總結。個人提高了也是專案整體提高的一部分。

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

加入測試

因為主要提供介面。一開始我們的都是自己測試，久而久之就沒有讓測試加入。

開始覺得這樣挺好，流程更短。

現在想我們的3個總結是：

1、我們其實做得工作並不少，反而多了，因為兼顧了測試的一部分工作

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

3、我們相信我們，但是我們還是不夠專業。就算是介面簡單不需要測試人員介入。

但是需要測試思維，測試的測試角度思維經常會給我們當頭一棒，很受用。

堅持執行，不斷調整

希望我能夠堅持執行，不斷反思調整。

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

自己近期看了很多敏捷相關的書籍，最近又看完的這一本，收穫還是很大的，糾正了很多原來的認知。

比如：所有的使用者故事必須符合6原則（其實是允許出現史詩級的使用者故事的）

總結

專案管理，甚至說軟體工程需要我們不斷吸收並反覆琢磨實踐。

自己立一個Flag 立一個願望，希望上述我們專案中存在的問題能夠在上半年有所改善。

能夠督促系統的成長和發展。

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