自覺良好
就在之前幾篇的時候，我們已經默默開始給小團隊灌輸靈活知識。
這個團隊很小，産品：快一年經驗；開發：畢業一年，初級程式員；還有一個有些經驗的我。
我們負責的項目有開發任務，同時也有不少運維工作。經常會有新需求插入和變更。
我們效仿一些靈活形式和方法。有些做得挺好，有些做得不能夠長期堅持。
我們産品清單比較混亂，沒有做整理細化，有一個摞一個。從外面看整個産品是混亂的，看不清未來方向的。
我們雖然每周都有計劃，從上面可以看出，我們沒有遠期目标。因為我的懶惰，沒有從項目上梳理長期的規劃。
自認為需求頻繁變動，是以沒必要清晰的長期規劃。也不是說沒有想過，讨論過，也達成一緻過。但是沒有落實到産品清單中。
你從産品清單中不會看到未來系統的模樣。
應屆生的産品做麼？他一直也是這麼做的，隻是有時我們稍微缺少了引導就會止步不前，不是積極性問題，是他有時真的無法下手。
就好比，你剛畢業就讓你負責系統架構一樣，我想剛畢業的我有心想做，但是心裡還是會戰戰兢兢。
冥冥之中的隐患
其實說到底還是項目管理的問題。我現在隐隐體會到，靈活是指導原則，實際貫穿主線的還是項目管理。
是以兩者的結合孕育出了很多的優秀的靈活實踐。
我們省去了産品清單的規劃，隻有零星的周計劃。我們甚至沒有了項目回顧會議。
我們起初所認為的快 —— 實際上是省去了各種産品清單的優先級排列：史詩級、主題級、沖刺級，由粗到細的使用者故事的拆分。
我們雖然将周期調整為一周一個計劃，來應對頻繁的運維需求的變更。但是我們也缺少了項目相關的評審會議、回顧會議。
我們隻管往前跑，冥冥之中感覺自己在做無用功，甚至說我們所做的任務價值意義不大。
導緻這種錯覺的，一個是很大程度上是沒有長遠規劃，另一個是各種評審和關鍵點沒有設卡，還有一個是沒有了回顧和檢討。
是以要遵循項目管理的主要規律和重要的實踐，雖然這些操作時間上付出是有一定的成本，這些付出是值得的。
需要長遠規劃
就好比大家沒有了共同的目标，這個不利于團隊的士氣，不利于項目的發展。
需要付出時間和精力來做這些事情，這個好比是架構，一部成長史。參與其中的成長是非常有成就的。
産品清單：史詩級使用者故事；主題級使用者故事；沖刺級使用者故事。沖刺級别是具體可執行的任務。
比如史詩級别：作為一個運維人員，我希望有一個背景可以友善我的日常運維工作，來提高處理問題的速度更快地相應客戶。
比如主題級别：作為一個使用者，我想我發起的任務可以并行排程而不是長時間等待順序排隊，這樣才能很快并陸續收到回報。
比如沖刺級别：作為一個運維人員，我在系統中能夠擁有線上對賬的權限，這樣利于月中對賬，而不是每次都需要寫郵件給DBA申請導出.
設卡&評審
關于評審，比如 核心子產品的設計評審（思路和技術點）
需求評審
接口協定的設計評審（命名，出入參）
代碼走查評審
測試用例評審
從各種評審中我收獲到的幾個基本的好處是：
1、對于被評審人員，專業技能上是一個肉眼可見的提升。
2、三個臭皮匠頂一個諸葛亮，大家不同的智慧的碰撞會發現很多新的坑。
3、是一種态度的輸出
其中幾個經驗是：
1、功夫都在平時準備：比如設計文檔、接口規範設計文檔、測試用例的用例（這個我們做的還行，也是需要導師多督促，成員能夠主動溝通）
2、會前，釋出一個會議大綱。（這個做得也行，這個都會說一下）
比如會議的主要讨論主題是什麼？會議的時間是多久？
自己會大約使用多長時間？留給其他人員的讨論時間是多少？
開會隻是一個對目前結果的一個讨論。
3、會議設定一個主持人
（這個很重要也很有效果，之前沒有主持人會議經常逾時。關鍵是逾時還覺得自豪，自豪會議又讨論出很多東西，自豪發言很踴躍。）
其實還是為了一個開會的效果，可以找一個資曆高一點的把控會議。避免過度讨論。
也就是大家的時間成本和開會的效果盡量地高效。
4、結束後整理會議紀要（這個執行得算是及格，但是不夠堅持）
其實會議紀要是次要的，主要是對會議讨論的結果負責，最好有産出物或者結論。
項目回顧
項目上的回顧，總結過去，計劃未來。
好的不好的都需要說。個人來說也是這樣，好的不好的都需要總結。個人提高了也是項目整體提高的一部分。
再就是計劃一下接下來的工作，明确下一個版本的目标。
加入測試
因為主要提供接口。一開始我們的都是自己測試，久而久之就沒有讓測試加入。
開始覺得這樣挺好，流程更短。
現在想我們的3個總結是：
1、我們其實做得工作并不少，反而多了，因為兼顧了測試的一部分工作
2、任務多了，有可能影響了工期和品質
3、我們相信我們，但是我們還是不夠專業。就算是接口簡單不需要測試人員介入。
但是需要測試思維，測試的測試角度思維經常會給我們當頭一棒，很受用。
堅持執行，不斷調整
希望我能夠堅持執行，不斷反思調整。
根據成員能力和專業程度采用相關的靈活實踐，不是所有市面上好的都有效。
自己近期看了很多靈活相關的書籍，最近又看完的這一本，收獲還是很大的，糾正了很多原來的認知。
比如：所有的使用者故事必須符合6原則（其實是允許出現史詩級的使用者故事的）
總結
項目管理，甚至說軟體工程需要我們不斷吸收并反複琢磨實踐。
自己立一個Flag 立一個願望，希望上述我們項目中存在的問題能夠在上半年有所改善。
能夠督促系統的成長和發展。
（喝茶水有點多，睡不着，深夜發個文章催眠一下）
更多精彩原創心得，請關注微信公衆号： 梯形