距離寫作《軟件開發模式：瀑布與敏捷》已經1年了，在新公司又帶了1年新團隊，中間陸續有看了一些軟件工程的文章，是時候寫點總結性的東西了。
我們知道要構建高質量軟件，就要解決軟件過程中的混亂，將軟件開發過程中的溝通、計劃、建模、構建和部署等活動有效地組織起來。
而軟件過程，就是在軟件項目的生命週期內，也就是軟件從誕生到結束這期間，在開發與構建系統時要遵循的步驟。
本文內容純屬漫談，希望對你有所啓發。
實用的每日站會和看板
覺得最實用的還是每日站會和任務看板。
每日站會控制在15分鐘左右，每個人都必須發言，並且要向所有成員當面彙報三個問題：
- 你昨天完成了什麼任務
- 今天要完成什麼目標
- 有什麼問題不能解決
每日站會的重要性在於，軟件開發細枝末節很多，如果不進行每天盤點，很容易失控。
下面是開發團隊裏經常發生的問題：
- 代碼缺少嚴苛的審覈環節，導致規範失效，給後續的運維帶來巨大的成本。
- 某個開發人員所謂的完成在交付測試的時候問題一大堆。
- 前後端開發人員沒有按約定開發，溝通也不及時，出現互相等待的無效浪費。
- 產品經理和開發人員互相扯皮，推脫責任，最後不知道聽誰的。
- 第一責任人缺失，等驗收的時候才發現大家都不知道有這檔事，最後延誤工期等等。
必須要有嚴苛的代碼審查機制
爲什麼是嚴苛而不是嚴格呢？代碼的質量反應了我們的產品質量，產品不穩定、老是出現BUG，直接影響客戶滿意度和口碑。
同時，代碼的好壞決定了未來運維的成本，如果因爲一時疏忽和妥協，回頭又沒有及時修改，中間又出現人員變動，那麼這份代碼的後患是無窮的。
因爲不規範，可讀性差，對交接人來說從心態上是本能反抗的，但是又不得不改，於是就一通亂改，能貼膏藥就貼膏藥，能運行就可以，管他規範不規範。這樣導致的後果是，代碼從不規範走向更加不規範，很難想象經過5-10年持之以恆的不規範，這個產品還能活着。
技術債務的危害怎麼形容都不爲過，輕則系統局部異常，中等的會導致修改困難，嚴重的需要推翻重來。
做產品，不嚴苛不足以長久。
開發人員要有產品經理的思維
開發人員習慣性陷入實現的細枝末節和局部思維，建議開發人員在開發之前，先不要去想如何實現。應該先問自己：
- 這個功能對用戶有什麼價值？
- 能爲公司創造價值嗎？
如果以上問題都是否定的，開發人員可以和產品經理理直氣壯的辯論甚至說NO。然而，現實當中，很多新手程序員接收到指令後，不管三七二十一，埋頭就敲代碼，這是很普遍的，因爲有個很好的說辭是：又不是我去調研的，我怎麼知道客戶想要什麼，再說了需求不對那是產品經理的鍋，反正和我沒關係。
這種意識非常危險，因爲產品經理也會有遺漏，一旦缺少質疑，等到開發完成，交付使用的時候被客戶否定了，那麼，失的不僅僅是時間和金錢的成本，還有團隊的戰鬥力和凝聚力，信任感，開發人員應該要有主人翁意識。
線上事故回溯討論會
爲了解決配合不積極和甩鍋的問題，可以考慮引入了線上事故回溯討論會，每兩週一次，對發生的事故進行討論，重在根因分析和以後如何避免，並事前強調目的不是追責。
因爲，每個故障分析都能暴露出藏在深處的問題，對提高產品質量和團隊間的信任效果都很好。
強調開發人員的主人翁意識
在團隊中，不同的角色對主人翁的理解從上往下，是逐級弱化的。
我覺得主人翁意識是一個被低估的褒義詞，這個詞渾身上下充滿了正能量，需要在團隊裏不斷的宣講，甚至寫成口號掛在牆上。
- 有主人翁意識的人通常做事一絲不苟，不輕易妥協，有工匠精神。
- 有主人翁意識的人，自我驅動能力都相對比較好，有事主動承擔，不叫苦，也不喊累，因爲對自己負責，所以能力一般也不會太差。
- 有主人翁意識的人，做事相對努力上進，人品也容易獲得肯定。
- 有主人翁意識的人，團隊的漏洞和危機更容易避免，團隊成員配合默契，無需繁重的章程和規定，效率槓桿。
- 有主人翁意識的人，通常會更願意幫助別人，見到別人文檔寫不完，一聲不吭就給你無私的支援。
- 有主人翁意識的人，公司的事就是自家的事，甚至要比自己的事更加負責任，因爲自己出錯大不了一個人承擔，公司的事影響的是一羣客戶。
- 有主人翁意識的人，更容易受到同事的尊重。因爲和這種同事搭檔，實在太輕鬆了。
- 有主人翁意識的人，集體意識好，願意承擔責任，凡事主動彙報，不用每次過問：“你任務完成得怎樣了云云”。
- 有主人翁意識的人，因爲對自己負責，所以更多意願自省，更多意願自驅，執行力不差，更容易拿到結果。
當負責人是有這種意識，整個團隊自熱而然會慢慢養成這種意識。
不要把重心放在研發流程本身
市面上講開發模式和流程的文章很多，不管研發流程多先進，是否出自大廠，我覺得都應該問自己團隊幾個問題：
- 這個開發模式適合當前的團隊規模嗎？
- 爲什麼我們要採用這個開發模式？
- 我們當前流程出了哪些問題？
- 哪些流程影響開發和交付效率？
- 當前的流程最致命的問題是什麼？
- 我們真的有必要修改當前的流程嗎？
只有找到當前團隊的症狀和問題，纔能有的放矢，對症下藥，否則很容易陷入教條主義，爲了流程而流程。比如某某大廠都這麼搞，我們也要這麼做；某個專家這麼說，我們也要這麼做。如果只是簡單照搬業界研發實踐的話，效果往往不好，有時甚至會造成負面效果。
流程規範過多，其實並不見得是好事，增加一條規範可能要考慮刪除一條，否則規範會變成枷鎖和負擔。
不僅僅是每日站會
站會雖然重要，但由於時間有限，並不能深刻的挖掘出那些深沉次的問題。所以不僅僅是每日站會的盤點，每個月應該都要有一份系統性的反思，從軟件工程的系統層面來反思，比如需求調研，產品設計，軟件設計，開發測試，實施運維等環節來深入剖析和總結。可參考愚文《關於盤點和總結的那點事兒》
不能僅僅是模式和流程
行文最後，我想潑一盆冷水：有了完美的開發模式和流程，你可能依然無法真正做好軟件開發。
因爲我們知道軟件工程從大的方面包括過程、方法、工具。瀑布和敏捷只不過是過程裏的兩個重要的模式，如果沒有方法和工具，整個軟件工程建設還是有問題的。
- 比如需求分析人員經驗欠缺，或者調研有偏差，那麼就會把團隊往坑裏帶；
- 如果系統架構和設計有缺陷，那麼後期可能無法能力複用，擴展困難，性能和穩定性會打折扣；
- 如果測試不專業，那麼產品質量就無法保證；
- 不善於使用工具，溝通和效率可能會打折扣；
- 如果不採用自動化，代碼人工合併、編譯和發佈，那就回到傳統低效的開發模式了。
未完待續
如何破解研發效率之道，要聊的內容實在太多了，除了軟件工程，可能還要研發效能、OKR、中國式管理等等，接下來會從系統的角度，結合平時踩過的坑，在學中記錄，在記錄中實踐再總結的方式，寫一個專欄，敬請期待……