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