《技術力量-一線技術團隊成功啓示錄》讀後感

        最近抽空拜讀了技術力量這本書，由於時間關係，目前只看完了前兩篇，即“團隊管理/組織發展”以及“測試管理/質量平臺”，對比自己的工作經歷和平時的思考，有些想法在此記錄。
        在“團隊管理/組織發展”章節中，共有來自十個不同類型公司的技術管理者分享他們的經驗，大至幾千人的團隊負責人，小的也帶領十來個人的開發團隊，公司類型覆蓋互聯網以及金融行業。
        第一篇文章中分享了微軟的基礎團隊對整個研發團隊的效率以及質量提升。其實，作爲一個有技術追求的公司，如果不僅僅滿足於做業務系統滿足業務需求，或者說當公司技術發展到一定階段，我認爲基礎服務團隊是有必要組建的。一個實力強勁的基礎團隊，可以規範不同團隊間混亂的架構、制定規範、提供基礎服務，減少大家重複建設重複踩坑的成本，同時提供高效穩定的基礎組件，提升代碼質量。然而，目前我們公司是相對欠缺這一塊的，我們還是一個比較分散的小團隊組織架構，每個項目在比較大程度上都是自由發揮，定義自己的規範和基礎服務包等。也許，隨着公司技術團隊的擴大，我們的架構組也會慢慢成長，從“業務架構”“技術架構”慢慢轉型成開發型的基礎服務團隊。拭目以待。
         整篇讀下來，可以看到，這些公司都在做團隊的敏捷的轉型，期望用敏捷的開發方式，提高技術團隊的研發效率、提升交付質量。最近幾年敏捷開發迅猛發展，人人都在談敏捷，而目前來看，其實大多數都只是學了敏捷的一個皮，很難真的貫徹精神。
         上一家公司是一家創業公司，技術團隊總共二十多人，產品、開發、測試坐一堆，業務就坐隔壁辦公室。雖然在開發中途，敏捷開始發展的時候，我們纔開始學習敏捷的工具和儀式，比如燃盡圖、“用戶故事”等，但是，在學習“敏捷”前，我認爲我們實際上已經在使用敏捷的思維在工作了：快速響應、快速迭代、早會、回顧會等，爲了提高上線速度和質量，還基於docker自主開發了持續集成一鍵上線的系統。我們不知道scrum是什麼，但是隨時保持和業務的溝通，以功能點代替了用戶故事，也能夠快速響應，甚至業務上午提的需求，晚上就能夠上線。
          然而，在當前的公司情況下，我覺得，敏捷是比較困難的：
         1.由於行業性質，公司對文檔、流程、規範等把控非常嚴格，一個業務想法，形成需求、完成討論、輸出設計等文檔、制定開發計劃、完成開發、SIT、UAT測試再走上線流程...我們不可能像業務期望中的敏捷那樣快速響應。
         2.此外，由於公司組織架構較大較複雜，人員也比較多，業務、需求分析（類似產品的角色）、開發、項目經理、測試同事、運維，都在不同的辦公點辦公，那麼，遇到問題，怎麼才能快速有效的溝通呢？一個項目對接的業務也不是固定的人，如果按照敏捷要求，是需要有這麼一個角色每天早上站會跟進和討論，甚至隨時調整需求，但是，在規範的流程限制下以及現實的辦公條件下，怎麼做到呢？
         3.還是由於行業性質問題，公司的網絡環境比較複雜，很難做到持續集成，快速上線。在書中第二篇也提到了測試的持續集成，有利於提高測試效率和輸出質量，但是目前我們的測試大多數仍然強依賴人力，複雜的網絡環境也有一定影響。當然，我們的測試團隊同事也在努力推動持續集成，期望自動化測試能夠減少人力成本、提高質量。
         總的來說，敏捷不僅僅是開發的事，而是需要業務、產品乃至整個公司的文化都要有敏捷的思維和行動模式，目前來看很難在短時間內很好的達成。我們目前能做的，就是吸取一些敏捷中容易落地的工具和儀式，比如故事點、站會、任務拆解、回顧會議等，再融合自身公司的開發流程和規範，期望走出符合自身公司特性的開發模式，能讓業務、開發、測試都舒服，讓領導也能更好的把控所有項目的進度和風險等。